IOT Cyber Security

Framework

TLP: White
 TLP: White

The Traffic light Protocol (TLP)

The Traffic Light Protocol (TLP) was created in order to facilitate greater sharing of
information. TLP is a set of designations used to ensure that sensitive information is shared
with the appropriate audience. It employs four colors to indicate expected sharing
boundaries to be applied by the recipient(s). The protocol includes four colors (traffic
lights), which are detailed as follows:

Red- Not for disclosure, restricted to participants only:

Sources may use TLP: RED when information cannot be effectively acted upon
by additional parties. Recipients may not share TLP: RED information with any
parties outside of the specific exchange, meeting, or conversation in which it
was originally disclosed

Amber- Limited disclosure, restricted to participants’ organizations:

Sources may use TLP: AMBER when information requires support to be
effectively acted upon, yet carries risks to privacy, reputation, or operations
if shared outside of the organizations involved. Recipients may only share TLP:
AMBER information with members of their own organization, and with clients or
customers who need to know the information to protect themselves or prevent
further harm.

Green- Limited disclosure, restricted to the community:

Sources may use TLP: GREEN when information is useful for the awareness of all
participating organizations as well as with peers within the broader community
or sector. Recipients may share TLP: GREEN information with peers and partner
organizations within their sector or community, but not via publicly accessible
channels.

White- Disclosure is not limited:

Sources may use TLP: WHITE when information carries minimal or no foreseeable
risk of misuse, in accordance with applicable rules and procedures for public
release. TLP: WHITE information may be distributed without restriction.

October 2022
TLP: White

ABOUT VERSION

3 October 2022
 TLP: White

TABLE OF CONTENTS

About Version 3
Table of Contents 4
Introduction 5
Definitions and Acronyms 8
The IoT Security Framework 10
High Level Security Controls 34
Technical Requirements 41
Conformity Assessment 80
List of tables and figures 85
References 88
Appendix-A: Case Study 90
Appendix-B: Disclaimer for Non Critical Infrastructure IoT Applications 100

4 October 2022
 TLP: White

INTRODUCTION
OVERVIEW

The Internet of Things (IoT) related products and services have been massively
expanding during the last decade. According to reports, there are billions of IoT
devices installed worldwide and the number is growing every year, meaning
more and more physical devices around the world that are connected to the
internet or other networks. Those IoT solutions are very attractive for cyber-
attacks due to the amount and type of information and control they possess.
It is crucial to protect the IoT devices so people and organizations do not fall
victim to cybercrimes.
As a result of that vast expansion of IoT products and services installed
throughout the world and specifically in Egypt. And to keep on the ARE’s vision
2030, of having multiple smart cities like «the new administrative capital». And
as it is the NTRA’s responsibility to ensure that people and organizations should
benefit from the available IoT smart products and services without the fear
of falling victim to cyber-attacks. It became essential for the NTRA to provide
a set of baseline security guidelines framework for IoT service providing
organizations, to ensure and improve the security of the IoT products and
associated services, as well as the privacy of consumers and organizations,
considering requirements applicable in the Arab Republic of Egypt.
The NTRA (National Telecom Regulatory Authority) is the official authority for
communication sector regulations in the Arab Republic of Egypt (ARE), that
is responsible for providing certifications and approvals for companies and
organizations willing to provide communication related solutions and services.
The NTRA has studied the most effective IoT security and cyber security
standards, guidelines and frameworks in the world that are relevant, applicable
and effective in the ARE.
And decided to provide this IoT security guidelines framework in the ARE,
according to law 10 of year 2003 about telecom regulation. This framework
brings together most effective IoT security guidelines and cyber security
assurance processes, in a sincere attempt to help IoT service providers in
securing their products and services by following a complete set of security
guidelines, activities and processes provided. Which ensures compliance with
the baseline security controls and requirements, and thus mitigating most
known attacks in their IoT products and services. The target is to make consumer
people and organizations benefit from their IoT devices and services securely,
safely and privately.

5 October 2022
 TLP: White

OBJECTIVE

This IoT security guidelines framework provides a security assurance process

accompanied with a set of baseline security requirements and controls
that assess and enhance the security of the IoT solutions of concern. The
framework follows well known and reliable worldwide IoT cyber security
standards and guidelines.
The framework aims to:

Encourage IoT service providing organizations to consider security and

privacy requirements throughout their IoT solutions and services.
Provide a set of baseline security requirements and controls which should
enhance security of IoT solutions.
Provide organized and well-defined procedures for IoT service providing
organizations to assess their IoT solutions security compliance with the
baseline requirements.
Provide a complete IoT security compliance questionnaire checklist sheet
to simplify the security assessment process of the IoT solution of concern for
the IoT service providers.
Ensure integrity, confidentiality and availability of the IoT products and
services consumed by organizations and end users in the ARE.

TARGET AUDIENCE

IoT service provider organizations running, deploying, operating, providing or

intending to run, deploy, operate, provide IoT device, system, service, solution
in the ARE who are subjected to consider the IoT security guidelines provided
in this document.
IoT Service Providers: Companies and organizations that provide services and
solutions required by the IoT system to operate. This includes networks, cloud
storage, data transfer and any other service required for the full IoT solution.

DISCLAIMER

This document provides a set of procedures and activities that will be carried
out by the service provider in order to ensure that the IoT solution under
investigation is secured enough for the target application.

6 October 2022
 TLP: White

It is the responsibility of the service provider which is using this guidelines to

carry out the IoT Security Assurance Process to ensure the following

1. They must reach a well understanding of the IoT solution under investigation
and the application and sectors into which the IoT solution is deployed.
2. They must ensure providing realistic and genuine information and evaluations
whenever required during the process.
3. They must ensure honesty and professionalism during the process and while
answering the questionnaire.

Any attempt to provide imperfect or misleading information or unrealistic

evaluations that may result in reaching inaccurate results must not be
tolerated. And the NTRA security staff has all the rights to request repeating
or re-evaluating any of the framework procedures or steps in order to provide
more accurate and realistic information and evaluations to fit criticality of the
IoT solution and the application into which it will be deployed.

DOCUMENT STRUCTURE

The remainder of this document consists of the following sections and

appendices:

● The Definitions and Acronyms used in this document are presented.

● Then the complete IoT Security guidelines framework is provided.
● Followed by the list of tables and list of figures present in the document.
● After that, References used are stated.
● Appendix-A: provides a step-by-step complete case study.
● Appendix-B: provides the Cyber-security disclaimer form for non critical
infrastructure applications.
● Appendix-C: provides the IoT Security Compliance Assessment
Questionnaire v1.1.

7 October 2022
TLP: White

DEFINITIONS AND ACRONYMS

TERMS AND DEFINITIONS

Attack surface All possible points (attack vectors), where an

unauthorized user can access a system. It is
the space that the attacker attacks.
Attack vector The method which a cyber attacker
uses to gain unauthorized access to the
system.
IoT vendor The IoT device manufacturing
organization.
IoT service Companies and organizations providing
provider services and solutions required for the IoT
system to operate.
IoT device The hardware devices designed for
certain applications, such as sensors,
actuators, gadgets, appliances and
other machines, that can collect and
exchange data over the Internet or other
networks.
IoT service The set of services provided by the
service provider for the IoT solution,
including the ability to connect to the
network.
IoT solution It can be all or any of the following:
IoT product, device, system, service or
solution.
The framework Whenever stated in this document,
it means the IoT security guidelines
framework in the ARE.
Responsible entity The entity, vendor or service provider,
which is responsible for considering and
maintaining a specific security guideline.

Threat An incident that could harm the system.

Vulnerabilities The ways in which assets can be
exploited.
Risk The potential for loss or damage when a
threat exploits a vulnerability.
8 October 2022
TLP: White

ACRONYMS

IoT The Internet of Things.

NTRA The National Telecom Regulatory
Authority.

ARE The Arab Republic of Egypt.

NIST The National Institute of Standards &

Technology.

IoTSF The Internet of Things Security

Foundation.
FIPS Federal Information Processing
Standards.

9 October 2022
 TLP: White

THE IOT SECURITY FRAMEWORK

ABOUT THE FRAMEWORK

The framework is intended to provide the essential security guidelines and

requirements that should be considered by IoT vendors and service providers.
These guidelines bring together the most effective IoT security considerations
in the field, which are applicable and do comply with the regulations and
security requirements of the IoT market of the ARE.

IOT APPLICATION CLASSIFICATION

Before digging into the IoT Security Assurance Process, the IoT solution of
interest should be initially classified according to figure1-. This must be initially
performed in order to decide whether the Iot solution of interest must proceed
through the IoT security assurance process aiming to assess its cybersecurity
according to the requirements provided later on, or that it can direct it into
just signing a disclaimer for non critical infrastructure applications, which is
provided in appendix-B.

Table1- provides the set of categories, subcategories and domains/sectors as

described by the executive regulations of law 175 of 2018 and the Egyptian
NTRA’s IoT Framework in the ARE. According to this table, the IoT solution of
interest can be classified into the proper category, thus deciding the suitable
path to follow, either signing the disclaimer, as explained in appendix-B, or
going through the security assurance process. The following sections provide
a detailed explanation of procedures and steps of activities of the security
assurance process along with expected outcomes and required inputs of
each one, also the set of responsibilities and commitments of stakeholders
through each activity.

10 October 2022
TLP: White

11 October 2022
TLP: White

12 October 2022
IOT SECURITY ASSURANCE PROCESS

The framework provides a set of security requirements for the IoT

service providers to comply with. This section describes the IoT
security assurance process that the responsible entity should
consider in order to assess the security of the IoT product or service
under consideration. The responsible entity should consider
following this process in order to reach a conclusion determining
whether the IoT solution under consideration complies with the
baseline security requirements or not.
The assurance process consists of a set of sequential activities,
required to be performed by the responsible entity (organization),
as briefly explained in figure-2, and then exhaustively explained in
figures 3, 4 and 5. It starts by performing a risk assessment activity as
explained in figure-3, the outcome of this activity is a risk register;
that is an ordered list of applicable risks with a risk score representing
impact of each.

Figure-2: IoT Security assurance process activities Overview

14
After that, the entity is required to determine the high-level security
requirements relevant and applicable for the use cases of concern.
Figure-4 explains this activity, where the responsible entity shall use
the generated risk register to determine the precise impact for
each security objective in the CIA-Triad, then consequently
determine the corresponding security class for each; that class is
used to relate to the applicable security requirements. Finally, a
conformity assessment activity is conducted as described in figure-
5; it involves an assessment questionnaire that shall be answered by
the entity. Entity should consider answering all questions applicable
to the security class determined in the previous step. It should
provide reasons and evidence for their answers wherever possible.
The resulting checklist clearly determines whether the IoT solution of
concern complies with the presented security baseline or not.

15
Figure-3: Risk Assessment Procedure

16
Figure-4: Defining Applicable High Level Security Controls
Procedure

17
Figure-5: Conformity Assessment Procedure
18
RISK ASSESSMENT

The risk assessment is the activity of identifying and prioritizing risks

to the organizational assets and operations. It is a critical activity as
it provides the foundation for the identified risks to be considered.
Normally, it is guided by the organization's risk management
process. During the ongoing process, IoT security risks are measured
and a score for the amount of risk observed is assigned. Figure-6
presents an overview of risk assessment main steps while figure-3
provides a sequential step-by-step flow-graph explaining each step
as well as its expected outcome to complete the risk assessment
activity.

Figure-6: Risk assessment activity main steps

The outcome of this activity is a comprehensive report that can
support the risk management team in their decision making. By
evaluating possible security threats and vulnerabilities over modules
of the IoT solution mainly based on their likelihood of occurrence
and impact they could have on the system, then prioritizing them
in order to define most effective threats and less effective ones. This
outcome is mandatory for the next step, as it is used to determine
the relevant CIA-Triad objectives and, consequently, the
corresponding security class, and related applicable security
requirements, as will be explained in later sections.
This will help the organizations, based on the characteristics of their
IoT solution, identify and mitigate the impact of security threats. By
determining which risks are applicable and must be treated, and

19
which risks are applicable but could be skipped; this is done in a
prioritized manner having high risk threats on top of the
organization’s focus going down to the least risky ones. By carrying
out this activity, organizations can examine their assets considering
the attacker’s perspective.
Risk assessment is a general concept that is commonly found in
cyber security as well as the business field. Many techniques have
been provided to conduct a risk assessment including some well-
known risk management standards, e.g., the National Institute of
Standards & Technology (NIST) "guide for conducting risk
assessments" (NIST standard SP 800-30r1), it is recommended to
revise the NIST standard SP 800-30r1 for better understanding. The
risk assessment process provided in this document follows main
steps presented by the NIST standard SP 800-30r1, which is one of
the most reliable related standards.
As explained in figure-3, each step depends on the outcome of its
previous step, so each one must be conducted in the described
sequence. Starting by identifying the use cases of interest, then
defining the applicable attack surface areas, vulnerabilities and
their impact. Followed by performing a risk analysis and evaluation
of the considered threats and vulnerabilities. After that, a risk
register of the resulting risk factors and scores is formulated and
documented. And finally, the risk analysis output document is
reviewed for reaching a decision. These steps may be repeated if
required, e.g., if the review step found that output is not clear or not
enough to conduct a decision.

USE CASE IDENTIFICATION

This is the first step in the risk assessment process, in which

organizations are required to identify and document the functional
use cases relevant to the IoT solution, representing functionality and
services provided, and their associated assets and attributes that
could be of interest to attackers.

20
 The outcome of this step is a list of detailed use cases of interest and
it is the base for the following steps; in which attack surface areas,
vulnerabilities and their impact that are relevant to each defined
use case are carefully identified. An example is provided in the
case study at Appendix-B.

ATTACK SURFACE AREA AND IMPACT IDENTIFICATION

An attack surface is the medium that is a part of the system that is

susceptible to hacking. This involves all points of access (attack
vectors) that an attacker or unauthorized person could use to hack
into the IoT system to manipulate data or extract data from the
system. It is the space that the attacker attacks. It is recommended
to keep the attack surface as small as possible; this makes it easier
to protect against attacks.
In order to carry out a risk assessment over the identified list of use
cases of interest, from the preceding step, organization is required
to identify the set of IoT attack surface areas that are applicable
over each use case. Identifying attack surface areas, vulnerabilities
and their impact is a base for the risk evaluation to be conducted,
as described in the coming up step.

Table-2 presents possible IoT attack surfaces, related vulnerabilities

and its impact. It can be used by the responsible entity to identify
which attack surface areas are applicable for the product/service
under investigation. According to the OWASP IoT project [OWASP-
IoT, IoT Attack Surface Areas OWASP. There are about 16 possible
IoT attack surfaces according to OWASP.

Attack
Vulnerabilities Possible Impact
Surface
■ Inject false reading.
■ Sensing Environment ■ Steal the device.
1. Hardware Manipulation. ■ Update the firmware
(Sensors) ■ Tampering (Physically). with malicious code
■ Damage (Physically). and take control of the
device.

21
Attack
Vulnerabilities Possible Impact
Surface
■ Sensitive data exposure ■ Access the secret keys,
(backdoor accounts, user credentials and
hardcoded credentials, organization
encryption keys, sensitive credentials.
information). ■ Unauthorized access to
■ Firmware version display the IoT system.
2. Device
and/or last update date. ■ Gain sensitive
Firmware
■ Vulnerable services (web, ssh, information about the
tftp, etc.). firmware.
■ Security related function API ■ Get sensitive URLs.
exposure. ■ Create backdoor
■ Firmware downgrade accounts through the
possibility. firmware.
■ Access security keys.
■ Unauthorized access
through stolen
credentials.
■ Sensitive data
■ Access data gathered
3. Device (Cleartext usernames,
by device’s sensors.
Memory cleartext passwords,
■ Ability to decrypt
encryption keys).
sensitive information
and communication
using stolen encryption
keys.
■ Get device ID.
■ Privilege escalation.
■ Firmware extraction.
■ Device malfunction.
■ User CLI.
■ Gain shell access to the
■ Admin CLI.
OS using physical
■ Privilege escalation.
interfaces.
4. Device ■ Reset to an insecure state.
■ Modifying the source
Physical ■ Removal of storage media.
code control flow graph
Interfaces ■ Tamper resistance.
to do malicious
■ Debug port (UART (Serial),
activities.
JTAG / SWD).
■ Attacker gains full
■ Device ID/Serial number
control over the device
exposure.
through a hacked
admin CLI.

22
Attack
Vulnerabilities Possible Impact
Surface
■ Exploit the web
interface of the
■ Standard set of web device/cloud.
application vulnerabilities ■ Discover security keys
(check OWASP Web Top 10, and credentials.
OWASP ASVS, OWASP Testing ■ Grant unauthorized
guide). access to the IoT system.
■ Credential management ■ Access data
5.
vulnerabilities transmitted.
Device/Clou
(Username enumeration, ■ Misuse of insecure
d Web
Weak passwords, Account password recovery
Interface
lockout, Known default mechanisms.
credentials, Insecure ■ Unauthorized access to
password recovery the system through cross
mechanism. site scripting.
■ Transport encryption. ■ Malicious code
■ Two-factor authentication. execution on the web
interface through XSS
exploit.

■ Information disclosure ■ Launch DoS, buffer

■ User CLI overflow and replay
6. Device
■ Administrative CLI attacks
Network
■ Injection ■ Prevent the transmission
Services
■ Denial of Service of legitimate data.
■ Unencrypted Services ■ Access sensitive data.

23
Attack
Vulnerabilities Possible Impact
Surface
■ Poorly implemented ■ Block legitimate Over-
encryption the-air (OTA) firmware
■ Test/Development Services update.
■ Buffer Overflow ■ Analyze network traffic.
■ UPnP ■ Privacy breach.
■ Vulnerable UDP Services ■ Integrity breach.
■ DoS ■ Access network security
■ Device Firmware OTA update keys and decrypt the
block communications.
■ Firmware loaded over ■ Grant unauthorized
insecure channel (no TLS) access to the IoT system.
■ Replay attack
■ Lack of payload verification
■ Lack of message integrity
check
■ Credential management
vulnerabilities (Username
enumeration, Weak
passwords, Account lockout,
Known default credentials,
Insecure password recovery
mechanism).
■ LAN ■ Prevent the transmission
■ LAN to Internet of legitimate data.
■ Short range ■ Get sensitive data and
7. Network
■ Non-standard information.
Traffic
■ Wireless (WiFi, Z-wave, XBee, ■ Analyze network traffic.
Zigbee, Bluetooth, LoRA) ■ Privacy breach.
■ Protocol fuzzing ■ Integrity breach.
■ Get a copy of the
■ Update sent without
firmware.
encryption
■ Inject a rogue firmware
■ Updates not signed
update to the device
8. Update ■ Update location writable
resulting in getting
Mechanism ■ Update verification
access to sensitive
■ Update authentication
information and modify
■ Malicious update
the code control flow
■ Missing update mechanism
graph.

24
Attack
Vulnerabilities Possible Impact
Surface
■ No manual update
mechanism

■ Implicitly trusted by device or

cloud
■ Access insecure data
■ Username enumeration
storage, log file
■ Account lockout
information and
■ Known default credentials
9. Mobile unencrypted traffic.
■ Weak passwords
Application ■ Misuse an insecure
■ Insecure data storage
password recovery
■ Transport encryption
mechanism and grant
■ Insecure password recovery
credentials.
mechanism
■ Two-factor authentication
■ Standard set of web
application vulnerabilities,
■ Attackers create a
(check OWASP Web Top 10,
backdoor account to
OWASP ASVS, OWASP Testing
take control over the
guide)
system.
■ Credential management
■ Access to device logs
vulnerabilities:
reveal information
(Username enumeration,
about the system and
10. Weak passwords, Account
users.
Administrativ lockout, Known default
■ Default credentials
e Interface credentials, Insecure
allow the hacker to take
password recovery
over the device or
mechanism.
service.
■ Security/encryption options
■ Lack of 2FA allows the
(Logging options, Two-factor
attacker to take over
authentication, Check for
the device using stolen
insecure direct object
credentials.
references, Inability to wipe
device)

25
Attack
Vulnerabilities Possible Impact
Surface
■ Authentication/Authorization
related values (session key,
token, cookie, etc.)
disclosure
■ Gain unauthorized
■ Reusing of session key, token,
access to the system.
etc.
■ Take control of the
■ Device to device
system
11. authentication
■ Change system
Authenticatio ■ Device to mobile Application
parameters and
n/ authentication
configuration.
Authorization ■ Device to cloud system
■ Inject malicious data.
authentication
■ Unauthorized access to
■ Mobile application to cloud
the system using a legit
system authentication
account.
■ Web application to cloud
system authentication
■ Lack of dynamic
authentication
■ Unencrypted data. ■ Discover secret
■ Data encrypted with credentials.
12. Local discovered keys. ■ Access sensitive
Data Storage ■ Lack of data integrity checks. information.
■ Use of static same enc/dec ■ Modify pre-stored
key. information.
■ Inherent trust of cloud or ■ Inject false data.
mobile application ■ Spy on sensitive data.
13. Vendor
■ Weak authentication ■ Rogue devices can
Backend
■ Weak access controls authenticate to the APIs
APIs
■ Injection attacks leading to taking down
■ Hidden services the whole service.
■ Inject false data.
■ Spy on sensitive data.
■ Unencrypted PII sent
14. Third- ■ Vulnerabilities in
■ Encrypted PII sent
party backend APIs may lead
■ Device information leaked
Backend APIs to privilege escalation,
■ Location leaked
unauthorized access,
and information leaks.

26
Attack
Vulnerabilities Possible Impact
Surface
■ User data disclosure ■ Access user’s personal
■ User/device location information.
15. Privacy
disclosure ■ User and organization
■ Differential privacy privacy breaches.
■ Interoperability standards.
■ Data governance.
■ Individual stakeholder risks.
■ Implicit trust between ■ Compromise of the
16. components. device or its related
Ecosystem ■ Enrollment security. components.
and ■ Decommissioning system. ■ System wide failure.
Communicati ■ Lost access procedures. ■ Manipulate exchanged
on ■ Health checks commands and
■ Heartbeats messages.
■ Ecosystem commands
■ Deprovisioning
■ Pushing updates
Table-2: IoT attack surfaces, related vulnerabilities and its impact

RISK ANALYSIS AND EVALUATION

This step aims to determine the risk factors of each applicable

threat (risk) for use cases of interest. It depends on the list of
vulnerabilities identified in the former step, providing each one a risk
score which represents how much effect this vulnerability has over
the IoT solution. The outcome is a list of risk factor scores for the
applicable threats and vulnerabilities to be documented and
prioritized in the risk register document in the next step.
Evaluating the risk score (risk factor) of a vulnerability requires
considering the likelihood or the probability at which the threat
could occur along with its impact and severity over the system or
the organization.

27
Risk analysis is highly subjective, that weights of probability levels
and of impact level should be determined by the organization.
Thus, the organization is required to formulate their own version of
the risk assessment matrix that is a combination of both likelihood
and impact levels, which shows the level of risk at each possible
combination. To evaluate threats of interest, the organization is
required to assess likelihood (probability) and impact (cost) levels
for each, based on their understanding of the use cases and its
characteristics.

DETERMINE THE LIKELIHOOD

Likelihood is the probability at which cyber security threat events of

interest could happen. The organization should assess the likelihood
of threat events while considering the characteristics of the use
cases of concern, including capability, intent and targeting. e.g., if
the threat event requires capabilities more than what the attackers
could have, then they are not expected to initiate that threat.

DETERMINE THE IMPACT

Impact is a measurement of the amount of harm, damage or loss

that could be caused if a potential threat event happened. The
organization has to determine the impact level caused by threat
events of concern, considering characteristics of the threat sources
which could initiate the events, identified vulnerabilities.

RISK ASSESSMENT MATRIX AND RISK SCORE

28
The risk assessment matrix is a combination of both likelihood
(probability) and impact (severity) of a vulnerability (or a threat). It
is a simple and effective method for organizations to assess the risks
of concern by defining its risk level, considering estimated likelihood
level of the events occurring and impact level that would result
from those events. In quantitative methods, risk levels are
commonly calculated as the product of the likelihood and impact
levels. However, in qualitative methods, it is evaluated by mapping
determined likelihood and impact levels to get the corresponding
risk level, e.g., a threat of Low likelihood and moderate impact has
an assessed risk level of moderate. The calculated level of risk
represents the degree to which the organization is threatened by
such events.
Table-3 presents an example of a classic 5x5 risk assessment matrix
between risk’s likelihood and impact (consequences/severity)
levels. Table-4 describes the risk score range for each risk level
rating. Tables 3 and 4 follow concepts provided by the NIST
standard SP 800-30r1 of the assessment scale tables (Appendix I,
table I-2) and (Appendix I, table I-3) respectively. Table-3 represents
risk levels in a qualitative manner, which could be converted into
quantitative by mapping respective score ranges provided in
table-4. This is a starting point that should be tailored and adjusted
by the organization for its specific conditions.

Impact Level
Moderat Very
Very Low Low High
e High
Multiple
Negligibl Limited Serious Severe
severe
e effect effect effect effect
effects
Very Almost Moderat Very
Very Low Low High
High certain e High
Moderat Very
High Highly likely Very Low Low High
e High
Li
k

Moderat Somewhat Moderat Moderat

Very Low Low High
e likely e e
Moderat
Low Unlikely Very Low Low Low Low
e

29
 Highly
Very Low Very Low Very Low Very Low Low Low
unlikely

Table-3: Risk assessment matrix [5x5 example]

Risk level Risk score Description

Very Low [0-4] Threat could be expected to have a negligible
effect.
Low [5-20] Threat could be expected to have a limited effect.
Moderate [21-79] Threat could be expected to have a serious effect.
High [80-95] Threat could be expected to have a severe or
catastrophic effect.

Very High [95-100] Threat could be expected to have multiple severe

or catastrophic effects.

Table-4: Risk levels and scores for risk assessment matrix described
in table-3
Another direct quantitative method for evaluating risk scores, is to
multiply the calculated likelihood (probability) value by the
calculated impact (cost) value directly. This will produce the risk
score as a quantitative value, which could be mapped into its
corresponding risk level using ranges defined in table-4.

DOCUMENT FINDINGS [RISK REGISTER]

After finishing the risk analysis step and providing risk factors and
scores of each threat, the organization’s team is required to well
document the results for review and decision making. The risk
register is an appropriate and organized way for documenting
these results. The organization should create a risk register
document based on the outcomes evaluated in the former step.

This risk register document should include all applicable threats with
their associated risk factor scores. In which threat events of concern
are ordered descending by the level of risk determined earlier, with

30
 the highest attention going to high-risk events. Risks of the same risk
level can be further prioritized by experience or based on their
quantitative risk factor scores. Thus, the risk with the highest risk score
should be at the top of the table going down to that of the least
score at the bottom. The reason for this prioritization criteria is to
guide and justify the word needed for the IoT solution’s security. This
work shall mainly focus on reducing the risk likelihood (probability)
factor to an acceptable level.

Risks with higher risk factors could highly compromise the IoT
solution, and must be highly and strictly considered for treatment
and mitigation; the organization should assign as many resources
as possible to decrease their risk factors. However, risks with lower
priority, having lower risk factors, can be postponed or even
neglected if their risk factor scores are not significant at all.
An example of a simplified risk register is presented in table-5,
however, the risk register document could have more columns with
extra information for each considered threat. This is the base for
determining the relevant security requirement, as will be explained
in later sections.

Risk
Impa Likelihoo Risk
Threat Description Level
ct d Factor
[Output]
An attacker could initiate an
unauthorized access attack to
Unauthoriz Very Very Very
access the IoT system for 97
ed access High High High
monitoring or pushing
information.
An attacker attacks the system
Denial of
to prevent devices from Very
service High 88 High
accessing the system’s High
attack
network.
An attacker dumps the
Firmware firmware from the IoT device Moderat Moderat
High 50
extraction chipset, to extract useful e e
information.

31
Table-5: Example of a simplified risk register

RISK ANALYSIS REVIEW AND UPDATE

The last, but not least, step of the risk assessment activity is to review
the output risk register document and the whole process output.

If the reviewers noticed any inconsistency of the results regarding

the identified use cases, or that threats or use cases are not well
identified or not well covering the IoT solution under investigation,
the whole process should be repeated and refined to solve found
issues.
If the results are well documented and organized, then the
document should provide a solid and organized source presenting
threats and vulnerabilities relevant to the IoT solution of interest. This
shall help the organization in deciding the order of threats by which
they should be investigated and mitigated; that higher priority
threats should be considered at first and may require higher
resources.

The final risk register is used by the following activity; it is the base to
determine the proper impact for each security objective
according to the CIA-Triad for the IoT solution under investigation,
that is consequently used to determine the corresponding security
class for the whole solution. The determined security class is the key
to determine the relevant security requirements, as described
through the next activity.

RESPONSIBILITIES & COMMITMENTS

32
 - It is the responsibility of the service provider to follow all steps
of the risk assessment activity and provide appropriate and
exact information as required, and to review and provide the
final risk register document.
- If requested by the service provider, the NTRA security staff is
responsible for auditing the activity output for approval or
rejection, with the aim of providing consultation concerning
the risk assessment procedure.

33
HIGH LEVEL SECURITY CONTROLS

OVERVIEW

The target of this section is to determine the required security

controls for the IoT application based on the actual use case and
the risk assessment. The security controls described in this
publication have a well-defined structure based on a risk
assessment approach derived from the CIA triad. The controls are
organized into 11 domains as described in this document based on
5 security levels according to the IoTSF (The Internet of Things
Security Foundation) Security Assurance Framework, as described
in table-9.
Depending on the use cases, the type of the provided service, the
market and the application in which the product is intended to be
used, the risk assessment determines the correct level of the security
controls which matches the CIA impact level. For example, a
home/small office Wi-Fi router used in connecting clients to the
internet, could be assessed under impact level 0 where the threat
is targeting individuals and is considered a low risk. However, when
deploying Wi-Fi in a train signaling control system, it could be
assessed under the highest impact level 5 because there is a very
high-level threat targeting the train control systems and affecting
the passengers’ life.
Figure-7 presents an overview of steps required to determine the
high level security controls applicable for the IoT solution of
concern. While figure-4 presents the sequential steps required to
perform this activity with the expected outcome of each step.

34
Figure-7: Defining applicable high level security controls procedure

THE CIA TRIAD

Following are definitions for the security objectives of the CIA triad:
● Confidentiality:
- Preserving authorized restrictions on information access and
disclosure, including means for protecting personal privacy
and proprietary information.
- Unauthorized access or unauthorized information disclosure is
considered a violation.
● Integrity:
- Guarding against improper information modification or
destruction, and includes ensuring information non-
repudiation and authenticity.
- Unauthorized modifications and manipulations are
considered a violation.
● Availability:
- Ensuring timely and reliable access to and use of information.
- Disrupting or denying access to the system or the information
is considered a violation.

35
 Based on these definitions, the impact levels are specified in Table-
6 as defined in FIPS 199 (FIPS: Federal Information Processing
Standards), Standards for Security Categorization of Federal
Information and Information Systems. These impact levels are used
later to determine the required security controls.

Objective Low Impact Moderate Impact High Impact

The unauthorized
The unauthorized The unauthorized
disclosure of
disclosure of disclosure of
information could
information could information could
be
be be
expected to have a
expected to have expected to
severe or
a have a
Confident catastrophic
limited adverse serious adverse
i-ality adverse
effect effect
effect on
on organizational on organizational
organizational
operations, operations,
operations,
organizational organizational
organizational
assets, assets,
assets,
or individuals. or individuals.
or individuals.
The unauthorized
The unauthorized The unauthorized
modification or
modification or modification or
destruction of
destruction of destruction of
information could
information could information could
be
be be
expected to have a
expected to have expected to
severe or
a have a
Integrity catastrophic
limited adverse serious adverse
adverse
effect effect
effect on
on organizational on organizational
organizational
operations, operations,
operations,
organizational organizational
organizational
assets, assets,
assets,
or individuals. or individuals.
or individuals.

36
 The disruption of The disruption of The disruption of
access to or use of access to or use access to or use of
information or an of information or an
information information or an information system
system information could be expected
could be system to
expected to could be have a severe or
Availabilit
have a limited expected to catastrophic
y
adverse have a serious adverse
effect on adverse effect on effect on
organizational organizational organizational
operations, operations, operations,
organizational organizational organizational
assets, assets, assets,
or individuals. or individuals. or individuals.
Table-6: CIA Triad impact levels explained

In order to apply an appropriate level of security assurance to a

service according to the IoTSF Security Framework, the
requirements in the Framework are classified to the following
classes:

Class Description
Where compromise to the data generated or loss of control
Class 0 is likely to result in little discernible impact on an individual or
organization.
Where compromise to the data generated or loss of control
Class 1 is likely to result in no more than limited impact on an
individual or organization.
In addition to class 1, the device is designed to resist attacks
on availability that would have significant impact on an
Class 2 individual or organization or impact many individuals. For
example, by limiting operations of an infrastructure to which
it is connected.
In addition to class 2, the device is designed to protect
Class 3 sensitive data including Personally identifiable information
(PII).
In addition to class 3, where compromise to the data
Class 4 generated or loss of control have the potential to affect
critical infrastructure or cause personal injury.

37
Table-7: Security requirement classes for the IoT Cybersecurity
framework

The security requirements classes in table-7 are mapped to the

corresponding impact levels of the CIA triad according to table-8.

Class Confidentiality Integrity Availability

Class 0 L L L
Class 1 L M M
Class 2 M M H
Class 3 H M H
Class 4 H H H

Table-8: Mapping security requirement classes to the CIA impact

levels
The following practical example can be used to explain
determining the security class. Consider an IoT smart meter
connected to the AMI system, the process can be as follows:
1. Determine the CIA impact:
A. Confidentiality is High since the smart meter stores
sensitive data such as the readings and tariff, and the
network stores sensitive information about the users
and meter controls which could have catastrophic
effect on user privacy and the smart grid network.
B. Integrity is Medium since poor data integrity can
cause readings manipulation resulting in a serious
effect on the organization.
C. Availability is High since a denial of service can cause
a complete power outage and is considered
catastrophic.
2. Determine the security requirements class:
which is class 3 in this case.
3. Determine security controls corresponding to the defined
security class:
For this case, all security controls marked as the
following
1. “Mandatory for class 3 and above”
2. “Mandatory for class 2 and above”
38
 3. “Mandatory for class 1 and above”
4. “Mandatory for all classes”
are all applicable and mandatory requirements
which should be considered.
The security technical requirements are organized into 11 Domains
according to table-9. These technical requirements describe the
required security controls for the service security level from a
technical point of view. For example, a service which has a class 4
security requirement must have data encryption quality according
to NIST.

Category Domain References

Device Hardware & Physical Security
Device Software
Device Operating System
Device Wired and Wireless Interfaces - NIST SP800-
Authentication and Authorization 53Ar5
Technical Encryption and Key Management for
Hardware - NIST SP800-
requirements
Cybersecurity State Awareness 213A
Web User Interface - IoTSF
Mobile Application
Cloud and Network Elements
Continuous assessments and monitor
Table-9: List of security requirements categories and domains\

RESPONSIBILITIES & COMMITMENTS

- It is the responsibility of the service provider to determine

impact levels on confidentiality (C), integrity (I) and
availability (A) for the solution under investigation, based on
the well understanding of the service, the application into
which the IoT solution is deployed and the identified use-
cases; while providing proper justification, reasoning and
evidence supporting the determined impact levels. And thus
determining the corresponding security class, according to
39
 the CIA triad impact levels approach for robust and clear
reasoning. The service provider must always ensure honesty
and professionality to provide realistic and genuine
evaluation of the IoT solution’s CIA-Triad security impact; for
ensuring accurate results.
- The NTRA security staff is responsible for auditing the
determined CIA objectives, the security class and the
corresponding applicable security controls, to ensure that the
calculated security controls are of enough and appropriate
security levels, in order to fit the criticality of the intended
target application.

40
TECHNICAL REQUIREMENTS

DEVICE HARDWARE AND PHYSICAL SECURITY

The service security includes the IoT device protection (If

applicable), communication system protection, and overall system
security. This section provides policies and controls required for
hardware and physical security of IoT devices. Including
requirements to mitigate device impersonation and
misconfiguration.
The following table lists these requirements and controls, it follows
the IoTSF Security Assurance Framework selected requirements from
2.4.4.1 through 2.4.4.18 and the NIST SP800-53Ar5 selected
requirements from CM-02 through CM-08, IA-03, AC-03, SI-04 and
SR-11

Req. Securit
Security Requirements
No y Class
Manda
HP- The product’s processor system has an irrevocable tory for
01 hardware Secure Boot process. all
classes
Manda
tory for
HP- The product’s processor system has an irrevocable
Class 2
02 “Trusted Root Hardware Secure Boot”
and
above
The product’s processor boot process provides an
Manda
appropriate level of trustworthiness by using a
tory for
HP- hardware root of trust to verify trusted boot or
Class 3
03 measured boot methods. This may be referred to as
and
'secure boot', but absolute security cannot be
above
assured.
Manda
HP- tory for
The Secure Boot process is enabled by default.
04 all
classes

41
Req. Securit
Security Requirements
No y Class
Any debug interface only communicates with Manda
authorized and authenticated entities on the tory for
HP-
production devices. Class 1
05
The functionality of any interface should be and
minimized to its essential task(s). above
Manda
The hardware incorporates protection against
tory for
HP- tampering and this has been enabled. The level of
Class 1
06 tamper protection must be determined by the risk
and
assessment.
above
Manda
The hardware incorporates physical, electrical and
tory for
HP- logical protection against tampering to reduce the
Class 2
07 attack surface. The level of protection must be
and
determined by the risk assessment.
above
Manda
The hardware incorporates physical, electrical &
tory for
HP- logical protection against reverse engineering. The
Class 3
08 level of protection must be determined by the risk
and
assessment.
above
Manda
All communications port(s) which are not used as
tory for
HP- part of the product’s normal operation are not
Class 1
09 physically accessible or only communicate with
and
authorized and authenticated entities.
above
Manda
All the product’s development test points are tory for
HP-
securely disabled or removed wherever possible in Class 2
10
production devices. and
above
Manda
Tamper Evident measures have been used to tory for
HP-
identify any interference to the assembly to the end Class 2
11
user. and
above
In production devices the microcontroller/ Manda
HP-
microprocessor(s) shall not allow the firmware to be tory for
12
read out of the products non-volatile [FLASH] Class 1

42
Req. Securit
Security Requirements
No y Class
memory. Where a separate non-volatile memory and
device is used the contents shall be encrypted. above
Where the product's credential/key storage is Manda
external to its processor, the storage and processor tory for
HP-
shall be cryptographically paired to prevent the Class 1
13
credential/key storage being used by unauthorized and
software. above
Manda
Where a production device has a CPU watchdog,
tory for
HP- it is enabled and will reset the device in the event
Class 1
14 of any unauthorized attempts to pause or suspend
and
the CPU’s execution.
above
Where the product has a hardware source for Manda
generating true random numbers, it is used for all tory for
HP-
relevant cryptographic operations including Class 1
15
nonce, initialization vector and key generation and
algorithms. above
Manda
tory for
HP- The product shall have a hardware source for
Class 2
16 generating true random numbers.
and
above
Manda
The product should have hardware mechanisms to tory for
HP-
control access to memory to reduce the risk of Class 3
17
running malicious code. and
above
DEVICE IDENTIFICATION AND AUTHENTICATION:
1. devices and/or types of devices to be Manda
HP- uniquely identified and authenticated before tory for
18 establishing a connection are defined; all
2. device ability to support unique device classes
identifier
Manda
Actions Based on Device Identity:
HP- tory for
1. Ability to configure IoT device access control
19 all
policies using IoT device identity.
classes

43
Req. Securit
Security Requirements
No y Class
2. Ability to hide IoT device identity from non-
authorized entities.
3. Ability for the IoT device to differentiate
between authorized and unauthorized
remote users.
4. Ability for the IoT device to differentiate
between authorized and unauthorized
physical device users (e.g., using a method of
authentication to verify the identity of
physical device users).
5. Ability to monitor specific actions based on
the IoT device identity.
6. Ability to identify software loaded on the IoT
device based on IoT device identity.
7. Ability for the device identifier to be used to
discover the IoT device for the purpose of
network asset identification and
management
Physical Identifiers: Manda
HP- 1. Ability to add a unique physical identifier at tory for
20 an external or internal location on the device all
authorized entities can access. classes
DEVICE CONFIGURATION: Manda
HP- 1. The capability to configure the IoT device tory for
21 through logical and/or physical interfaces to all
meet organizational requirements. classes
Table-10: Device hardware and physical security Policies, and
controls

DEVICE SOFTWARE

This section provides a set of policies, controls and considerations

required for securing the device software. Including controls for
securing remote software updates, communication, memory

44
 access, software reversion, sensitive information, inputs and
outputs, device boot, configuration, maintenance and storage.

The following table lists these requirements and controls, it follows

the IoTSF Security Assurance Framework selected requirements from
2.4.5.1 through 2.4.5.41 and the NIST SP800-53Ar5 selected
requirements from CM-02 through CM-07, MA-03, SA-10, CP-9, CP-
9(8), MP-06 and SC-28.

Req. Securit
Security Requirements
No y Class
The product has measures to prevent unauthorized and
Manda
unauthenticated software, configurations and files being
DS- tory for
loaded onto it. If the product is intended to allow
01 all
unauthenticated software, such software should only be
classes
run with limited permissions and/or sandbox.
Where remote software updates can be supported by
Manda
the device, the software images must be digitally signed
DS- tory for
by an appropriate signing authority - e.g.,
02 all
manufacturer/supplier or public. The Signing Authority
classes
should be clearly identified.
Where updates are supported, the software update Manda
DS- package has its digital signature, signing certificate and tory for
03 signing certificate chain verified by the device before the all
update process begins. classes
Manda
If remote software upgrade is supported by a device, tory for
DS-
software images shall be encrypted or transferred over Class 2
04
an encrypted channel. and
above
If the product has any virtual port(s) that are not required
for normal operation, they are only allowed to
communicate with authorized and authenticated Manda
entities or are securely disabled when shipped. When a tory for
DS-
port is initialized or used for field diagnostics, the port Class 2
05
input commands are deactivated and the output and
provides no information which could compromise the above
device, such as credentials, memory address or function
names.

45
Req. Securit
Security Requirements
No y Class
Manda
To prevent the stalling or disruption of the device’s tory for
DS-
software operation, watchdog timers are present, and Class 1
06
cannot be disabled. and
above
Manda
tory for
DS- The product’s software signing root of trust is stored in
Class 1
07 tamper-resistant memory.
and
above
Manda
The product has protection against unauthorized
tory for
DS- reversion of the software to an earlier and potentially less
Class 2
08 secure version. Only authorized entities can restore the
and
software to an earlier secure version.
above
Manda
There are measures to prevent the installation of non- tory for
DS-
production (e.g., development or debug) software onto Class 1
09
production devices. and
above
Manda
Production software images shall be compiled in such a
tory for
DS- way that all unnecessary debug and symbolic
Class 1
10 information is removed, to prevent accidental release of
and
superfluous data.
above
Manda
Development software versions have any debug
tory for
DS- functionality switched off if the software is operated on
Class 2
11 the product outside of the product vendor’s trusted
and
environment.
above
Manda
Steps have been taken to protect the product's software tory for
DS-
from sensitive information leakage, including at network Class 3
12
interfaces during initialization, and side-channel attacks. and
above
Manda
DS- The product’s software source code follows the basic
tory for
13 good practice of a language subset coding standard.
Class 2

46
Req. Securit
Security Requirements
No y Class
and
above
Manda
The product’s software source code follows the basic tory for
DS-
good practice of static vulnerability analysis by the Class 2
14
developer. and
above
The software must be architected to identify and ring
fence sensitive software components, including
Manda
cryptographic processes, to aid inspection, review and
tory for
DS- test. The access from other software components must
Class 1
15 be controlled and restricted to known and acceptable
and
operations. For example, security related processes
above
should be executed at higher privilege levels in the
application processor hardware.
Manda
tory for
DS- Software source code is developed, tested and
Class 1
16 maintained following defined repeatable processes.
and
above
Manda
The build environment and toolchain used to compile the tory for
DS-
application is run on a build system with controlled and Class 2
17
auditable access. and
above
Manda
The build environment and toolchain used to create the tory for
DS-
software is under configuration management and Class 2
18
version control, and its integrity is validated regularly. and
above
Manda
DS- Where present, production software signing keys are tory for
19 under access control. all
classes
The production software signing keys are stored and Manda
DS-
secured in a storage device compliant to FIPS-140-2/FIPS- tory for
20
140-3 level 2, or equivalent or higher standard. Class 1

47
Req. Securit
Security Requirements
No y Class
and
above
Manda
Where the device software communicates with a
tory for
DS- product related web server or application over TCP/IP or
Class 2
21 UDP/IP, the device software uses certificate pinning or
and
public/private key equivalent, where appropriate.
above
For a device with no possibility of a software update, the
Manda
conditions for and period of replacement support should
DS- tory for
be clear. A replacement strategy must be
22 all
communicated to the user, including a schedule for
classes
when the device should be replaced or isolated.
Manda
All inputs and outputs are checked for validity e.g., use
tory for
DS- “Fuzzing” tests to check for acceptable responses or
Class 2
23 output for both expected (valid) and unexpected
and
(invalid) input stimuli.
above
The software has been designed to meet the safety
Manda
requirements identified in the risk assessment; for
tory for
DS- example, in the case of unexpected invalid inputs, or
Class 2
24 erroneous software operation, the product does not
and
become dangerous, or compromise security of other
above
connected systems.
Support for partially installing updates is provided for Advisor
DS-
devices whose on-time is insufficient for the complete y for all
25
installation of a whole update (constrained devices). classes
Advisor
DS- Support for partially downloading updates is provided for
y for all
26 devices whose network access is limited or sporadic.
classes
Where real-time expectations of performance are
present, update mechanisms must not interfere with Manda
DS- meeting these expectations (e.g., by running update tory for
27 processes at low priority, or notifying the user of the all
priority and duration of the update and with the option classes
of postponing or disabling the update).
Where a device doesn’t support secure boot, upon a
DS- Manda
firmware update the user data and credentials should be
28 tory for
re-initialized.

48
Req. Securit
Security Requirements
No y Class
all
classes
Where a device cannot verify authenticity of updates Manda
DS- itself (e.g., due to no cryptographic capabilities), only a tory for
29 local update by a physically present user is permitted all
and is their responsibility. classes
An update to a device must be authenticated before it
Manda
is installed. Where the update fails authentication, the
DS- tory for
device should, if possible, revert to the last known good
30 all
(current stable) configuration/software image which was
classes
stored on the device.
Manda
There is secure provisioning of cryptographic keys for tory for
DS-
updates during manufacture in accordance with Class 1
31
industry standards. and
above
Memory locations used to store sensitive material (e.g.,
Manda
cryptographic keys, passwords/passphrases, etc.) are
tory for
DS- sanitized as soon as possible after they are no longer
Class 2
32 needed. These can include but are not limited to
and
locations on the heap, the stack, and statically-allocated
above
storage.
Manda
Any caches which potentially store sensitive material are tory for
DS-
cleared flushed after memory locations containing Class 3
33
sensitive material have been sanitized. and
above
An end-of-life policy shall be published which 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. The need for each update should
Manda
be made clear to users and an update should be easy to
DS- tory for
implement. At the end of the support period, the device
34 all
should reduce the risk of a latent vulnerability being
classes
exploited. This could be by indicating an error condition
to the user or curtailing functionality. This action should be
clearly communicated to the user during the
procurement stage.

49
Req. Securit
Security Requirements
No y Class
Updates should be provided for a period appropriate to
the device, and this period shall be made clear to a user Manda
DS- when supplying the device. Updates should, where tory for
35 possible, be configurable to be automatically or all
manually installed. The supply chain partners should classes
inform the user that an update is required.
The device manufacturer should ensure that shared
libraries (e.g., Clib or Crypto libraries) that deliver network
and security functionalities have been reviewed or Manda
evaluated (note that the actual review or evaluation tory for
DS-
does not have to be conducted by the manufacturer if Class 2
36
it has been conducted by another reputable and
organization or government entity). Cryptography above
libraries should be re-reviewed for known security
vulnerabilities on each update of the device.
Manda
tory for
DS- Maintenance changes should trigger full security
Class 2
37 regression testing.
and
above
Manda
tory for
DS- IoT devices must allow software updates to maintain
Class 2
38 security over the product lifetime.
and
above
Manda
Hard-coded critical/ security parameters in device
DS- tory for
software source code shall not be used; if needed these
39 all
should be injected in a separate (secure) process.
classes
Where the device is capable, it should check after Manda
initialization, and then periodically, whether security tory for
DS-
updates are available, either autonomously or as part of Class 1
40
the support service. Otherwise, the support service should and
push updates to the device. above
Manda
BASELINE CONFIGURATION:
DS- tory for
1. automated mechanisms for maintaining baseline
41 all
configuration of the system are defined;
classes

50
Req. Securit
Security Requirements
No y Class
2. software programs not authorized to execute on
the system are defined;
3. frequency at which to review and update the list of
unauthorized software programs is defined;
MAINTENANCE TOOLS: Manda
DS- 1. maintenance tools are inspected to ensure that tory for
42 the latest software updates and patches are all
installed. classes
DEVELOPER CONFIGURATION MANAGEMENT: Manda
DS- 1. the developer of the system, system component, or tory for
43 system service is required to enable integrity all
verification of software and firmware components. classes
Secure Storage:
1. Ability to support encryption of data at rest
2. Ability to cryptographically store passwords at rest,
as well as device identity and other authentication
data
3. Ability to support data encryption and signing to
prevent data from being altered in device storage. Manda
4. Ability to secure data in device storage. tory for
DS-
5. Ability to secure data stored locally on the device. Class 1
44
6. Ability to secure data stored in remote storage areas and
(e.g., cloud, server, etc.). above
7. Ability to utilize separate storage partitions for
system and user data.
8. Ability to securely back-up the data on the IoT
device.
9. Ability to “sanitize” or “purge” specific or all data in
the device.
Table-11: Device software Policies, and controls

DEVICE OPERATING SYSTEM

This section provides policies, controls and considerations required

for securing the device’s operating system. Including controls for
system update, system accounts, passwords, system services, OS

51
 kernel, execution, resource usage, device integrity and device
operations.

The following table lists these requirements and controls, it follows

the IoTSF Security Assurance Framework selected requirements from
2.4.6.1 through 2.4.6.15 and the NIST SP800-53Ar5 selected
requirements from SC-02 through SC-51, PE-10 through PE-15, CM-
02 through CM-08, CP-10, CP-12, SI-06, SI-17, CA-09(1), SR-09, SR-
09(1) and IR-04(5)

Req. Security
Security Requirements
No Class
Mandat
ory for
DO- The OS is implemented with relevant security updates prior
Class 2
01 to release.
and
above
Mandat
All unnecessary accounts or logins have been disabled or
ory for
DO- eliminated from the software at the end of the software
Class 1
02 development process, e.g., development or debug
and
accounts and tools.
above
Mandat
ory for
DO- Files, directories and persistent data are set to minimum
Class 1
03 access privileges required to correctly function.
and
above
Security parameters and passwords should not be hard-
Mandat
coded into source code or stored in a local file. If
ory for
DO- passwords absolutely must be stored in a local file, then the
Class 1
04 password file(s) are owned by, and are only accessible to
and
and writable by, the Device's OS most privileged account
above
and are obfuscated.
Mandat
ory for
DO- All OS non-essential services have been removed from the
Class 1
05 product’s software, image or file systems.
and
above
DO- All OS command line access to the most privileged Mandat
06 accounts has been removed from the OS ory for

52
Req. Security
Security Requirements
No Class
Class 1
and
above
All of the product’s OS kernel and services or functions are Mandat
disabled by default unless specifically required. Essential ory for
DO-
kernel, services or functions are prevented from being Class 1
07
called by unauthorized external product level interfaces and
and applications. above
Mandat
All software is operated at the least privilege level possible ory for
DO-
and only has access to the resources needed as controlled Class 1
08
through appropriate access control mechanisms. and
above
Mandat
ory for
DO- All the applicable security features supported by the OS
Class 1
09 are enabled.
and
above
Mandat
ory for
DO- The OS is separated from the application(s) and is only
Class 1
10 accessible via defined secure interfaces.
and
above
Mandat
ory for
DO- The OS implements a separation architecture to separate
Class 2
11 trusted from untrusted applications.
and
above
The product’s OS kernel is designed such that each Mandat
component runs with the least security privilege required ory for
DO-
(e.g. a microkernel architecture), and the minimum Class 2
12
functionality needed. (2.4.6.6/8 requires non-essential and
components to be disabled or removed). above.
The Product OS should be reviewed for known security Mandat
vulnerabilities particularly in the field of cryptography prior ory for
DO-
to each update and after release. Cryptographic Class 1
13
algorithms, primitives, libraries and protocols should be and
updateable to address any vulnerabilities. above

53
Req. Security
Security Requirements
No Class
Mandat
ory for
DO- The user interface is protected by an automatic session idle
Class 1
14 logout timeout function.
and
above
Secure Execution:
1. Ability to enforce organizationally-defined execution
policies.
2. Ability to execute code in confined virtual Mandat
environments. ory for
DO-
3. Ability to separate IoT device processes into Class 2
15
separate execution domains. and
4. Ability to separate the levels of IoT device user above
functionality.
5. Ability to authorize various levels of IoT device
functionality.
Secure Resource Usage:
1. Ability to support shared system resources.
2. Ability to release resources back to the system.
3. Ability to separate user and process resources.
4. Ability to manage memory address space assigned
to processes.
5. Ability to enforce access to memory space through
the kernel.
Mandat
6. Ability to prevent a process from accessing memory
ory for
DO- space of another process.
Class 1
16 7. Ability to enforce configured disk quotas.
and
8. Ability to continue operation when associated
above
networks are unavailable (e.g., a smart smoke
detector must still go off when a fire occurs even if it
is not attached to the associated network).
9. Ability to provide sufficient resources to store and run
the operating environment (e.g., operating systems,
firmware, applications).
10. Ability to utilize file compression technologies (e.g., to
provide denial of service protection).

54
Req. Security
Security Requirements
No Class
11.Ability to use or enforce hardware-based, write
protection to protect certain software (e.g.,
firmware).
Device Integrity:
1. Ability to perform security compliance checks on
system components (e.g., verify acceptable baseline
configuration, perform a tamper check).
2. Ability to detect unauthorized hardware and
software components and other tampering with the
Mandat
IoT device when used.
ory for
DO- 3. Ability to detect tampering throughout the system
Class 2
17 development life cycle.
and
4. Ability to take organizationally-defined actions when
above
unauthorized hardware and software components
are detected (e.g., disallow a flash drive to be
connected even if a USB port is present).
5. Ability to store the operating environment (e.g.,
firmware image, software, applications) in read-only
media (e.g., Read Only Memory).
Secure Device Operation:
1. Ability to keep an accurate internal system time.
2. Ability to compare and synchronize internal system
time with an organizationally defined authoritative
source.
3. Ability to define various operational states.
Mandat
4. Ability to support various modes of IoT device
ory for
DO- operation with more restrictive operational states.
Class 2
18 5. Ability to define differing failure types.
and
6. Ability to fail in a secure state.
above
7. Ability to disable operations and/or functionality in the
event of security violations.
8. Ability to restrict components/features of the IoT
device (e.g., ports, functions, protocols, services, etc.)
in accordance with organizationally-defined policies.

Table-12: Device OS Policies, and controls

55
 DEVICE WIRED AND WIRELESS INTERFACES

This section provides policies, controls and considerations required

for securing both wired and wireless interfaces of the device, which
are used to communicate with the device through some network.
It Includes controls for securing connection, network configuration,
unauthorized changes, system ports, connection passwords,
authentication, communication keys, relevant communication
protocols, communication availability and confidentiality, critical
operations and misconfiguration.
The following table lists these requirements and controls, it follows
the IoTSF Security Assurance Framework requirements 2.4.7.1
through 2.4.7.25

Req. Security
Security Requirements
No Class
Mandat
ory for
DW- The product prevents unauthorized connections to it or
Class 1
01 other devices the product is connected to.
and
above
Mandat
The network component and firewall (if applicable) ory for
DW-
configuration has been reviewed and documented for Class 1
02
the required/defined secure behavior. and
above
Mandat
To prevent bridging of security domains within products ory for
DW-
with network interfaces, forwarding functions should be Class 1
03
blocked by default. and
above
Mandat
Devices support only the versions of application layer ory for
DW-
protocols that have been reviewed and evaluated Class 1
04
against publicly known vulnerabilities. and
above

56
Req. Security
Security Requirements
No Class
If a potential unauthorized change is detected (e.g.: an
access fails authentication or integrity checks), the Mandat
device should alert the user/administrator to the issue ory for
DW-
and should not connect to wider networks than those Class 1
05
necessary to perform the alerting function. Failed and
attempts should be logged, but without providing any above
information about the failure to the initiator.
Mandat
ory for
DW- All the product's unused ports (or interfaces) are closed
Class 1
06 and only the necessary ones are active.
and
above
Mandat
If a connection requires a password or passcode or
DW- ory for
passkey for connection authentication, the factory issued
07 all
or reset password is unique to each device.
classes
Mandat
Where using the initial pairing process, a Strong
ory for
DW- Authentication shall be used, requiring physical
Class 1
08 interaction with the device or possession of a shared
and
secret.
above
Mandat
Where a wireless interface has an initial pairing process,
DW- ory for
the passkeys are changed from the factory issued, or
09 all
reset password prior to providing normal service.
classes
For any Wi-Fi connection, WPA-2 AES or a similar strength Mandat
encryption has been used. Migration to the latest ory for
DW-
standard should be planned. (e.g., WPA3) Older insecure Class 1
10
protocols such as WEP, WPA/WPA2 (Auto), WPA-TKIP and and
WPA-2 TKIP/AES (Mixed Mode) are disabled. above
Mandat
Where WPA-2 WPS is used it has a unique, random key ory for
DW-
per device and enforces exponentially increasing retry Class 1
11
attempt delays. and
above
Mandat
DW- All network communications keys are stored securely, in
ory for
12 accordance with industry standards.
Class 1

57
Req. Security
Security Requirements
No Class
and
above
Mandat
Where a TCP protocol, such as MQTT, is used, it is ory for
DW-
protected by a TLS connection with no known Class 1
13
vulnerabilities. and
above
Mandat
Where a UDP protocol is used, such as CoAP, it is ory for
DW-
protected by a DTLS connection with no known Class 1
14
vulnerabilities. and
above
Where cryptographic suites are used such as TLS, all Mandat
cipher suites shall be listed and validated against the ory for
DW-
current security recommendations such as NIST 800-131A Class 1
15
or OWASP. Where insecure ciphers suites are identified and
they shall be removed from the product. above
Mandat
All use of cryptography by the product, such as TLS cipher
ory for
DW- suites, shall be listed and validated against the
Class 1
16 import/export requirements for the territories where the
and
product is to be sold and/or shipped.
above
Mandat
ory for
DW- Where there is a loss of communications or availability it
Class 1
17 shall not compromise the local integrity of the device.
and
above
Mandat
The product only initializes and enables the
ory for
DW- communications interfaces, network protocols,
Class 1
18 application protocols and network services necessary for
and
the product’s operation.
above
Mandat
Communications protocols should be the latest versions ory for
DW-
with no publicly known vulnerabilities and/or appropriate Class 1
19
for the product. and
above

58
Req. Security
Security Requirements
No Class
Mandat
Post product launch, communications protocols should
ory for
DW- be reviewed throughout the product life cycle against
Class 1
20 publicly known vulnerabilities and changed to the most
and
secure versions available if appropriate.
above
Mandat
ory for
DW- If a factory reset is made, the device should warn that
Class 1
21 secure operation may be compromised until updated.
and
above
Where RF communications are enabled (e.g., ZigBee, Advisor
DW-
etc.) antenna power is configured to limit the ability of y for all
22
mapping assets to limit attacks such as WAR-Driving. classes
Advisor
DW- Protocol anonymity features are enabled in protocols
y for all
23 (e.g., Bluetooth) to limit location tracking capabilities.
classes
Mandat
As far as reasonably possible, devices should remain ory for
DW-
operating and locally functional in the case of a loss of Class 1
24
network connection. and
above
Following restoration of power or network connection, Mandat
devices should be able to return to a network in a sensible ory for
DW-
state and in an orderly fashion, rather than in a massive Class 1
25
scale reconnect, which collectively could overwhelm a and
network. above
Table-13: Device wireless and wired interfaces security Policies,
and controls

AUTHENTICATION AND AUTHORIZATION

This section provides policies, controls and considerations for system

authentication and authorization security. It includes controls for
mitigating tampering, impersonation, creating weak passwords,
brute force repeated login attempts, unauthorized access and

59
 securing passwords creation, passwords storing, password recovery
and reset, passwords entry and device authentication and
identification.

The following table lists these requirements and controls, it follows

the IoTSF Security Assurance Framework requirements 2.4.8.1
through 2.4.8.18 and the NIST SP800-53Ar5 selected requirements
from IA-02 through IA-06 and AC-17(10)

Req. Security
Security Requirements
No Class
The product contains a unique and tamper-resistant
device identifier. E.g., the chip serial number or other
Manda
unique silicon identifier, for example to bind code and
AA- tory for
data to a specific device hardware. This is to mitigate
01 all
threats from cloning and also to ensure authentication
classes
may be done assuredly using the device identifier e.g.,
using a device certificate containing the device identifier.
Manda
tory for
AA- Where the product has a secure source of time there is a
Class 1
02 method of validating its integrity.
and
above
Where a user interface password is used for login
Manda
authentication, the factory issued or reset password is
AA- tory for
randomly unique for every device in the product family. If
03 all
a password-less authentication is used the same principles
classes
of uniqueness apply.
Manda
AA- The product does not accept the use of null or blank tory for
04 passwords. all
classes
Manda
The product will not allow new passwords containing the
AA- tory for
user account name with which the user account is
05 all
associated.
classes
Manda
Password entry follows industry standard practice on
AA- tory for
password length, characters from the groupings and
06 all
special characters.
classes

60
Req. Security
Security Requirements
No Class
Manda
The product has defense against brute force repeated tory for
AA-
login attempts, such as exponentially increasing retry Class 1
07
attempt delays. and
above
Manda
The product securely stores any passwords using an tory for
AA-
industry standard cryptographic algorithm, compliant with Class 1
08
an industry standard. and
above
Manda
The product supports access control measures to the tory for
AA-
root/highest privilege account to restrict access to Class 1
09
sensitive information or system processes. and
above
Manda
tory for
AA- The access control privileges are defined, justified and
Class 1
10 documented.
and
above
Manda
The product only allows controlled user account access; tory for
AA-
access using anonymous or guest user accounts is not Class 1
11
supported without justification. and
above
The product allows the factory issued or OEM login Advisor
AA-
accounts to be disabled or erased or renamed when y for all
12
installed or commissioned. classes
Manda
The product supports having any or all of the factory
AA- tory for
default user login passwords altered when installed or
13 all
commissioned.
classes
Manda
If the product has a password recovery or reset
tory for
AA- mechanism, an assessment has been made to confirm
Class 1
14 that this mechanism cannot readily be abused by an
and
unauthorized party.
above

61
Req. Security
Security Requirements
No Class
Manda
tory for
AA- Where passwords are entered on a user interface, the
Class 1
15 actual pass phrase is obscured by default.
and
above
Advisor
AA- The product allows an authorized and complete factory
y for all
16 reset of all of the device’s authorization information.
classes
Where the product has the ability to remotely recover from Manda
attack, it should rely on a known good state, to enable tory for
AA-
safe recovery and updating of the device, but should limit Class 1
17
access to sensitive assets until the device is in a known and
secure condition. above
Manda
tory for
AA- Devices are provided with a RoT-backed unique
Class 1
18 authenticable logical identity.
and
above
Manda
Device Authentication Support:
tory for
AA- 1. Ability for the IoT device to identify itself as an
Class 1
19 authorized entity to other devices.
and
2. Ability to verify the identity of other devices.
above
Authentication Support:
1. Ability for the IoT device to require authentication prior
to connecting to the device, including using remote
access.
2. Ability for the IoT device to support and require Manda
appropriate authentication. tory for
AA-
3. Ability for the IoT device to support a second, or more, Class 1
20
authentication method(s) through an out of band path and
such as: Temporary passwords or other one-use logon above
credentials, Third-party credential checks, Biometrics,
Text messages, other methods
4. Ability for the IoT device to hide or mask authentication
information during the authentication process.

62
 Table-14: Device Authentication and Authorization Policies, and
controls.

ENCRYPTION AND KEY MANAGEMENT FOR HARDWARE

This section provides policies, controls and considerations for

encryption and key management security. It includes controls for
securing security parameters, keys confidentiality, cryptographic
functions, sensitive parameters storing, private keys, cryptographic
capabilities and key management, data transmission and security
and privacy attributes transmission.

The following table lists these requirements and controls, it follows

the IoTSF Security Assurance Framework requirements 2.4.9.2
through 2.4.9.11 and the NIST SP800-53Ar5 selected requirements
from SC-02 through SC-28 and SA-9(6)

Req. Security
Security Requirements
No Class
Mandat
ory for
If present, a true random number generator source has
EK-01 Class 2
been validated for true randomness.
and
above
Mandat
There is a process for secure provisioning of security
ory for
parameters and keys that includes random and
EK-02 Class 2
individual (unique) generation, distribution, update,
and
revocation and destruction.
above
Mandat
ory for
There is a secure method of key insertion that protects
EK-03 Class 1
keys against copying.
and
above
All the product related cryptographic functions have
Mandat
no publicly known unmitigated weaknesses in the
EK-04 ory for
algorithms or implementation, for example MD5, SHA-1,
Class 1
and DES are not used.

63
Req. Security
Security Requirements
No Class
and
above
Mandat
All the product related cryptographic functions are
ory for
sufficiently secure for the lifecycle of the product, or
EK-05 Class 1
cryptographic algorithms and primitives should be
and
updateable ("crypto agility").
above
Mandat
The product stores all sensitive unencrypted ory for
EK-06 parameters (e.g., keys) in a secure, tamper-resistant Class 1
location. and
above
The cryptographic key chain used for signing
Advisory
production software is different from that used for any
EK-07 for all
other test, development or other software images or
classes
support requirement.
Mandat
In device manufacture, all asymmetric encryption
ory for
private keys that are unique to each device are
EK-08 Class 2
secured. They must be truly randomly internally
and
generated or securely programmed into each device.
above
Mandat
ory for
All key lengths are sufficient for the level of assurance
EK-09 Class 2
required.
and
above
Mandat
In systems with many layered sub devices, key ory for
EK-10
management should follow best practice. all
classes
Cryptography Capabilities and Support:
1. Ability to execute cryptographic mechanisms of Mandat
appropriate strength and performance. ory for
EK-11 2. Ability to obtain and validate certificates. Class 2
3. Ability to verify digital signatures. and
4. Ability to run hashing algorithms (i.e., compute and above
compare hashes).

64
Req. Security
Security Requirements
No Class
5. Ability to perform authenticated encryption
algorithms.
Cryptographic Key Management:
2. Ability to manage cryptographic keys securely
Mandat
3. Ability to generate key pairs.
ory for
4. Ability to store encryption keys securely.
EK-12 Class 2
5. Ability to change keys securely.
and
6. Ability to maintain exclusive control of
above
cryptographic keys when used by external
systems.
Secure Transmission:
1. Ability to configure the cryptographic algorithm to
protect data in transit.
2. Ability to support trusted data exchange with a
specified minimum strength cryptography
algorithm.
Mandat
3. Ability to support data encryption and signing to
ory for
EK-13 prevent data from being altered in transit.
all
4. Ability to utilize one or more capabilities to protect
classes
the data it transmits from unauthorized access
and modification.
5. Ability to use cryptographic means to validate the
integrity of data transmitted.
6. Ability to use organization-internal normalized
formats to protect the data it transmits.
SEPARATION OF SYSTEM AND USER FUNCTIONALITY:
Mandat
1. user functionality, including user interface services,
ory for
is separated from system management
EK-14 Class 2
functionality
and
2. state information is stored separately from
above
applications and software
TRANSMISSION OF SECURITY AND PRIVACY ATTRIBUTES:
1. the integrity of transmitted security attributes is Mandat
verified ory for
EK-15 2. the integrity of transmitted privacy attributes is Class 1
verified. and
3. anti-spoofing mechanisms are implemented to above
prevent adversaries from falsifying the security

65
Req. Security
Security Requirements
No Class
attributes indicating the successful application of
the security process
Mandat
ory for
EK-16 Information at rest requiring protection is defined; Class 1
and
above
Table-15: Encryption and key management security Policies, and
controls

CYBERSECURITY STATE AWARENESS

This section provides policies, controls and considerations for

cybersecurity state awareness, it is required to add ability to get
information about the cybersecurity state of the IoT device. It
includes controls for getting access to events information,
identification, monitoring and response.

The following table lists these requirements and controls, it follows

the NIST SP800-53Ar5 selected requirements from AU-02 through AU-
13, SC-07 through SC-42, SI-04, CM-03, CM-06, CA-07, IA-02, CP-13,
IR-04 and RA-07.

Req. Security
Security Requirements
No Class
Access to Event Information:
1. Ability to access information about the IoT
Mandatory
CS-01 device's cybersecurity state and other
for all classes
necessary data.
2. Ability to preserve system state information.
Event Identification & Monitoring:
1. Ability to identify organizationally-defined
Mandatory
CS-02 cybersecurity events (e.g., expected state
for all classes
change) that may occur on or involving the
IoT device.

66
Req. Security
Security Requirements
No Class
2. Ability to monitor for organizationally-defined
cybersecurity events (e.g., expected state
change) that may occur on or involving the
IoT device.
3. Ability to support a list of events that are
necessary for auditing purposes (to support
the organizational auditing policy).
4. Ability to identify unique users interacting with
the device (to allow for user session
monitoring).
5. Ability to support a monitoring process to
check for disclosure of organizational
information to unauthorized entities. (The
device may be able to perform this check
itself or provide the information necessary for
an external process to check)
6. Ability to monitor communications traffic.
7. Ability to monitor changes to the
configuration settings.
8. Ability to detect remote activation attempts.
9. Ability to define the characteristics of
unapproved content.
10. A
bility to scan files for unapproved content.
Event Response:
7. Ability to generate alerts for specific
events.
8. Ability to respond to alerts according to
predefined responses.
9. Ability to alert connected information Mandatory
CS-03 systems of potential issues found during the for Class 2
auditing process. and above
10. Ability to provide information to an external
process that will issue auditing process
alerts.
11. Ability to notify users of activation of a
collaborative computing device.

67
Req. Security
Security Requirements
No Class
12. Ability to provide a physical indicator of
sensor use.
13. Ability to respond following an auditing
failure (either by the device or an external
auditing process).
14. Ability to prevent download of
unapproved content
15. Ability to delete unapproved content.
16. Ability to support alternative security
mechanisms when primary mechanisms
(e.g., login protocol, encryption, etc.) are
compromised.
17. Ability to configure organizationally-
defined aspects of the event response.
Table-16: Cybersecurity state awareness Policies, and controls

WEB USER INTERFACE

This section provides policies, controls and considerations for web

user interface security. Including controls for securing management
and login authentication, access roles, user passwords, password
entry, data transfer, sessions, inputs and outputs, web interfaces
and personal data communication.
The following table lists these requirements and controls, it follows
the IoTSF Security Assurance Framework selected requirements from
2.4.10.1 through 2.4.10.19

Req Security
Security Requirements
. No Class
Mandat
Where the product or service provides a web-based user ory for
UI-
interface, Authentication is secured using current best Class 1
01
practice cryptography. and
above

68
Req Security
Security Requirements
. No Class
Mandat
Where the product or service provides a web browser- ory for
UI-
based interface, access to any restricted/administrator Class 1
02
area or functionality shall require authentication. and
above
Mandat
Where the product or service provides a web-based ory for
UI-
management interface, Authentication is secured using Class 1
03
current best practice cryptography. and
above
Mandat
Where a web user interface password is used for login
UI- ory for
authentication, the initial password or factory reset
04 all
password is unique for every device in the product family.
classes
Mandat
ory for
UI- The web user interface is protected by an automatic
Class 1
05 session idle logout timeout function.
and
above
Mandat
UI- ory for
User passwords are not stored in plain text.
06 all
classes
Mandat
ory for
UI- Strong passwords are required, and a random salt value
Class 1
07 is incorporated with the password.
and
above
Mandat
Where passwords are entered on a user interface, the ory for
UI-
actual pass phrase is obscured by default to prevent the Class 1
08
capture of passwords. and
above
Mandat
ory for
UI- The web user interface shall follow good practice
Class 1
09 guidelines.
and
above

69
Req Security
Security Requirements
. No Class
Mandat
A vulnerability assessment has been performed before ory for
UI-
deployment and is repeated periodically throughout the Class 1
10
lifecycle of the service or product. and
above
Mandat
All data being transferred over interfaces should be
ory for
UI- validated where appropriate. This could include
Class 1
11 checking the data type, length, format, range,
and
authenticity, origin and frequency.
above
Mandat
Sanitize input in Web applications by using URL encoding ory for
UI-
or HTML encoding to wrap data and treat it as literal text Class 1
12
rather than executable script. and
above
Mandat
All inputs and outputs are validated using for example an ory for
UI-
allow list (formerly 'whitelist') containing authorized origins Class 1
13
of data and valid attributes of such data. and
above
Mandat
Administration Interfaces are accessible only by
ory for
UI- authorized operators. Mutual Authentication is used over
Class 1
14 administration interfaces, for example, by using
and
certificates.
above
Mandat
Reduce the lifetime of sessions to mitigate the risk of
ory for
UI- session hijacking and replay attacks. (For example, to
Class 1
15 reduce the time an attacker has to capture a session
and
cookie and use it to access an application).
above
Mandat
All inputs and outputs are checked for validity. Tests to ory for
UI-
include both expected (valid) and unexpected (invalid) Class 1
16
input stimuli. and
above
Mandat
UI- Web Interfaces should be developed using best practice
ory for
17 secure coding techniques and server frameworks.
Class 1

70
Req Security
Security Requirements
. No Class
and
above
Mandat
UI- ory for
Password entry follows industry standard practice.
18 all
classes
Mandat
Web interface should provide a simple method (one to
UI- ory for
two clicks) to initiate any security update to the end
19 all
device.
classes
Any personal data communicated between the web Mandat
UI- interface and the device shall be encrypted. Where the ory for
20 data includes sensitive personal data then the all
encryption must be appropriately secure. classes
Table-17: Web UI Policies, and controls

MOBILE APPLICATION

This section provides policies, controls and considerations for

securing mobile applications used with IoT solutions. It includes
controls for securing user interface passwords, password entry,
databases and files, connection to remote servers, passwords
storage, data transfer, configuration management, inputs and
outputs, application updates, network access and personal data
communication.

The following table lists these requirements and controls, it follows

the IoTSF Security Assurance Framework requirements 2.4.11.1
through 2.4.11.13

Req. Security
Security Requirements
No Class
Where an application’s user interface password is used Mandat
MA- for login authentication, the initial password or factory ory for
01 reset password is unique to each device in the product all
family. classes
71
Req. Security
Security Requirements
No Class
Mandat
MA- ory for
Password entry follows industry standard practice.
02 all
classes
Mandat
The mobile application ensures that any related
ory for
MA- databases or files are either tamper resistant or restricted
Class 1
03 in their access. Upon detection of tampering of the
and
databases or files, they are re-initialized.
above
Mandat
Where the application communicates with a product ory for
MA-
related remote server(s), or device, it does so over a Class 1
04
secure connection. and
above
Mandat
ory for
MA- The product securely stores any passwords using an
Class 1
05 industry standard cryptographic algorithm.
and
above
Mandat
Where passwords are entered on a user interface, the ory for
MA-
actual pass phrase is obscured by default to prevent the Class 1
06
capture of passwords. and
above
Mandat
All data being transferred over interfaces should be
ory for
MA- validated where appropriate. This could include
Class 1
07 checking the data type, length, format, range,
and
authenticity, origin and frequency.
above
Secure Administration Interfaces; It is important that Mandat
configuration management functionality is accessible ory for
MA-
only by authorized operators and administrators. Enforce Class 1
08
Strong Authentication over administration interfaces, for and
example, by using certificates. above
All application inputs and outputs are validated using for Mandat
MA-
example a allowed list containing authorized origins of ory for
09
data and valid attributes of such data. Class 1

72
Req. Security
Security Requirements
No Class
and
above
Mandat
ory for
MA- Mobile Apps should be developed using best practice
Class 1
10 secure coding techniques and server frameworks.
and
above
Mandat
App interface should provide a simple method (one to ory for
MA-
two clicks) to initiate any security update to the end Class 1
11
device. and
above
Mandat
Access to device functionality via a network/web
ory for
MA- browser interface in the initialized state should only be
Class 1
12 permitted after successful Authentication using current
and
best practice secure cryptographic modules.
above
Mandat
Any personal data communicated between the mobile
ory for
MA- app and the device shall be encrypted. Where the data
Class 1
13 includes sensitive personal data then the encryption
and
must be appropriately secure.
above
Table-18: Mobile application security Policies, and controls.

CLOUD AND NETWORK ELEMENTS

This section provides policies, controls and considerations for

securing the cloud and network elements used by the IoT solution.
It includes controls for securing operating system, web services,
web services protocols, web servers, communication through the
web, user passwords, passwords storage, unauthenticated access,
service availability, cloud communication, device identity and
configuration, user roles, API keys, related cloud services, cloud
databases, remote access and personal data communication;

73
 and mitigating password brute force attacks, DDOS attacks and
malfunctioning or malicious activities.

The following table lists these requirements and controls, it follows

the IoTSF Security Assurance Framework selected requirements from
2.4.13.1 through 2.4.13.36

Req. Security
Security Requirements
No Class
Mandat
All the product related cloud and network elements
ory for
CN- have the latest operating system(s) security updates
Class 2
01 implemented and processes are in place to keep them
and
updated.
above
Mandat
Any product related web servers have their web server ory for
CN-
identification options (e.g., Apache or Linux) switched Class 1
02
off. and
above
Mandat
ory for
CN- All product related web servers have their web server
Class 1
03 HTTP trace and trace methods disabled.
and
above
Mandat
All the product related web servers’ TLS certificate(s) are
ory for
CN- signed by trusted certificate authorities; are within their
Class 1
04 validity period; and processes are in place for their
and
renewal.
above
Mandat
The Product Manufacturer or Service Provider has a
ory for
CN- process to monitor the relevant security advisories to
Class 1
05 ensure all the product related web servers use protocols
and
with no publicly known weaknesses.
above
The product related web servers support appropriately Advisor
CN-
secure TLS/DTLS ciphers and disable/remove support for y for all
06
deprecated ciphers. classes
Mandat
CN- The product related web servers have repeated
ory for
07 renegotiation of TLS connections disabled.
Class 1

74
Req. Security
Security Requirements
No Class
and
above
Mandat
ory for
CN-
The related servers have unused IP ports disabled. Class 1
08
and
above
Mandat
Where a product related to a web server encrypted
ory for
CN- communications using TLS and requests a client
Class 1
09 certificate, the server(s) only establishes a connection if
and
the client certificate and its chain of trust are valid.
above
Where a product related to a web server encrypted Advisor
CN-
communications using TLS, certificate pinning is y for all
10
implemented. classes
Mandat
ory for
CN- All the related servers and network elements prevent the
Class 1
11 use of null or blank passwords.
and
above
Mandat
ory for
CN- All the related servers and network elements enforce
Class 1
12 passwords that follow industry good practice.
and
above
Mandat
Brute force attacks are impeded by introducing
ory for
CN- escalating delays following failed user account login
Class 1
13 attempts, and/or a maximum permissible number of
and
consecutive failed attempts.
above
Mandat
All the related servers and network elements store any ory for
CN-
passwords using a cryptographic implementation using Class 1
14
industry standard cryptographic algorithms. and
above
All the related servers and network elements support Mandat
CN-
access control measures to restrict access to sensitive ory for
15
information or system processes to privileged accounts. Class 1

75
Req. Security
Security Requirements
No Class
and
above
Mandat
All the related servers and network elements prevent ory for
CN-
anonymous/guest access except for read only access to Class 1
16
public information. and
above
Advisor
CN- If run as a cloud service, the service meets industry
y for all
17 standard cloud security principles.
classes
Mandat
Where a Product or Services includes any safety critical
ory for
CN- or life-impacting functionality, the services infrastructure
Class 2
18 shall incorporate protection against DDOS attacks, such
and
as dropping of traffic or sink-holing.
above
Mandat
Where a Product or Service includes any safety critical or
ory for
CN- life-impacting functionality, the services infrastructure
Class 1
19 shall incorporate redundancy to ensure service
and
continuity and availability.
above
Mandat
ory for
CN- Input data validation should be maintained in
Class 1
20 accordance with industry best practice methods.
and
above
Mandat
If run as a cloud service, the cloud service TCP based
ory for
CN- communications (such as MQTT connections) are
Class 1
21 encrypted and authenticated using the latest TLS
and
standard.
above
Mandat
If run as a cloud service, UDP-based communications are ory for
CN-
encrypted using the latest Datagram Transport Layer Class 1
22
Security (DTLS). and
above
Where device identity and/or configuration registries Mandat
CN-
(e.g., "thing shadows") are implemented to "on-board" ory for
23
devices within a cloud service, the registries are Class 1

76
Req. Security
Security Requirements
No Class
configured to restrict access to only authorized and
administrators. above
Mandat
Product-related cloud services bind API keys to specific ory for
CN-
IoT applications and are not installed on non-authorized Class 2
24
devices. and
above
Mandat
CN- Product-related cloud services API keys are not hard- ory for
25 coded into devices or applications. all
classes
Mandat
If run as a cloud service, privileged roles are defined and ory for
CN-
implemented for any gateway/service that can Class 2
26
configure devices. and
above
Mandat
ory for
CN- Product-related cloud service databases are encrypted
Class 1
27 during storage.
and
above
Mandat
Product-related cloud service databases restrict ory for
CN-
read/write access to only authorized individuals, devices Class 1
28
and services. and
above
Mandat
Product-related cloud services are designed using a
ory for
CN- defense-in-depth architecture consisting of Virtual
Class 1
29 Private Clouds (VPCs), firewalled access, and cloud-
and
based monitoring.
above
Mandat
ory for
CN- When implemented as a cloud service, all remote access
Class 1
30 to cloud services is via secure means (e.g., SSH).
and
above

77
Req. Security
Security Requirements
No Class
Mandat
Product-related cloud services monitor for compliance ory for
CN-
with connection policies and report out-of-compliance Class 2
31
connection attempts. and
above
Mandat
IoT edge devices should connect to cloud services using ory for
CN-
secure hardware and services (e.g., TLS using private keys Class 1
32
stored in secure hardware). and
above
Mandat
Any personal data communicated between the mobile
ory for
CN- app and the device shall be encrypted. Where the data
Class 2
33 includes sensitive personal data then the encryption must
and
be appropriately secure.
above
Mandat
Subject to user permission, telemetry data from the ory for
CN-
device should be analyzed for anomalous behavior to Class 2
34
detect malfunctioning or malicious activity. and
above
Table-19: Cloud and Network elements security Policies, and
controls.

CONTINUOUS ASSESSMENT AND MONITOR

This section provides policies, controls and considerations for

continuous assessments and monitoring of the IoT solution. It
includes controls for developing assessment plans, gaining cyber
security certifications, regular assessment and penetration testing
and monitoring cyber security status of the IoT solution.The following
table lists these requirements and controls, it follows the NIST SP800-
53Ar5 selected requirements from CA-02 through CA-08, CM-08,
MA-03

78
Req. Security
Security Requirements
No Class
Develop a control assessment plan that describes the
scope of the assessment including: Mandat
1. Controls and control enhancements under assessment; ory for
AM-
2. Assessment procedures to be used to determine control Class 2
01
effectiveness; and and
3. Assessment environment, assessment team, and above
assessment roles and responsibilities;

The IoT service provider and the provided IoT

Mandat
service/devices (can be hardware, firmware, cloud...etc.)
ory for
AM- must pass at least one cyber security certifications process
Class 3
02 matching the service domain. E.g., hardware can be
and
certified from common criteria or PSA, sensitive
above
software/firmware can be certified from common criteria.
Mandat
1) Conduct regular penetration testing on the provided
ory for
AM- services.
Class 2
03 2) The frequency and the scope of the penetration testing
and
process must be defined.
above
1. The service's cyber security status and privacy status
Mandat
must be monitored in real time.
ory for
AM- 2. Any new discovered vulnerabilities need to be
Class 2
04 patched.
and
3. Vulnerabilities in 3rd party software/firmware must be
above
patched.
1) All the service components must receive regular
software, firmware, and hardware updates.
Mandato
2) The frequency of the updates must be defined.
AM-05 ry for all
3) The libraries and other 3rd party software/firmware
classes
components must be updated regularly to the latest
versions.

Table-20: Continuous assessment and monitor Policies, and

controls.

79
CONFORMITY ASSESSMENT

OVERVIEW

Conformity assessment is the final step of the IoT security assurance

process, where conformity with the relevant security requirements
is assessed with evidence. Figure-8 presents an overview of steps to
complete the conformity assessment procedure, sequential steps
and expected outcomes to perform this activity are provided in
figure-5.

Figure-8: Conformity assessment procedure.

To do so, an IoT security compliance assessment questionnaire

checklist covering the key requirements-based questions is
provided, as an audit and assessment tool. Every requirement
under questioning is accompanied with its corresponding
applicable security classes. The organization shall answer questions
of requirements covering the applicable security classes to
determine the conformity of the service providing organization,
and the IoT solution to the cybersecurity framework.

Based on the outcomes of the risk assessment activity, the

applicable security classes, for the solution of concern, are
determined as discussed earlier in the framework; then the
80
applicable security requirements are automatically derived
according to the corresponding security class in the tool. And then,
the organization is ready to go through answering the security
compliance assessment questionnaire.
The organization shall answer all questions applicable on the
determined security class of the IoT solution of concern. It should
provide supporting evidence and reasons for their answers
wherever possible. The resulting checklist answers should clearly
verify whether the IoT solution of concern complies with the
presented security baseline requirements or not. This compliance
assessment questionnaire is intended to help organizations achieve
high quality, informed security choices by guiding users through a
robust checklist and evidence collecting process.

THE IOT SECURITY COMPLIANCE QUESTIONNAIRE

The IoT security compliance assessment questionnaire document is

a part of the IoT Security Guidelines Framework in the ARE. It
provides a security assessment questionnaire checklist to guide IoT
service providing organizations through a security assessment
process while collecting well-structured evidence and reasons,
based on IoT security best practices and requirements. After
completing this checklist, organizations should be able to
determine the compliance level of the IoT solution of concern.
Few foundations have provided security compliance
questionnaires and checklists for the IoT and cyber security in
general. The IoT security compliance assessment questionnaire
provided with this framework follows applicable requirements from
the IoT Security Compliance Framework provided by IoTSF (Internet
of Things Security Foundation) and from the NIST SP800-53Ar5, where
both are considered reliable and solid frameworks for relevant
guidelines and standards.
The IoT security compliance assessment questionnaire can be
found in Appendix-C. It is also available in a separate document as
an editable sheet for interested organizations, which should
81
facilitate the process of completing the questionnaire by adding
answers directly in the sheet. The editable sheet is attached to the
framework and available upon request.

This assessment questionnaire is intended to help organizations

achieve high quality, informed security choices by guiding them
through a robust checklist and evidence collecting process.

USING THE ASSESSMENT QUESTIONNAIRE

The process is guided by the category of the IoT solution under

investigation and the corresponding applicable security class. In
order to use this checklist questionnaire, the organization should first
consider the IoT Security assurance process.
A risk assessment process should be first conducted in order to find
applicable risk levels and factors, that is used to determine the
precise impact for each security objective, confidentiality, integrity
and availability levels (CIA-Triad); then consequently determine the
corresponding security class for each, thus determining applicable
security controls and requirements. For the detailed process and
extra demonstration, please refer to the IoT Security assurance
process.

COMPLIANCE CHECKLIST

The responsible organization's members shall answer each

requirement by providing a response, evidence and a reason.

Mar
No Response Description
k
1 C Compliant The requirement is fully satisfied.
Partially
2 PC The requirement is partially satisfied.
Compliant
3 NC Not Compliant The requirement is not satisfied.

82
 The requirement is not applicable for
4 N/A Not Applicable
the IoT solution of concern.

Table-21: Checklist response options.

Response: Response is selected from 4 options as shown and
described in table-21.
Evidence: The response should be supplied by an evidence
document ensuring the provided response, wherever possible.
Reason: A reason should be provided whenever needed to justify
the provided response.

ASSESSMENT METHODOLOGY

The assessment method is affected by the context (here, technical)

and the class. Together, they define the type of assessment, e.g.,
physical testing, software review or document review, along with
the degree of firmness, from self-assessment for lower classes to full
third-party audit for high classes.
After the service provider fills the questionnaire checklist document
with the required input, an audit and review process are started by
the NTRA to determine whether both the service providing
organization and the provided technical service are compliant with
the cybersecurity framework or not. After audition and review, the
NTRA then provides a security compliance assessment report with
the resulting compliance level decision, along with
recommendations and suggestions.

RESPONSIBILITIES & COMMITMENTS

- It is the responsibility of the service provider to provide

accurate and realistic responses to the applicable security
controls’ questions. They must also provide relevant evidence,
reasons and date of answering the question.
83
 - The NTRA security staff is responsible for auditing responses of
the compliance questionnaire and verifying whether answers
are valid and accurate or not, and if accurate they are
responsible for auditing whether the IoT solution is approved
or rejected depending on the level of compliance to the IoT
Security Compliance Questionnaire.
- The NTRA security staff has all the rights to request repeating
any process on the condition that they detected any means
of providing misleading information or unrealistic evaluations
through answers and outcomes generated by the service
provider.

RESPONSIBILITIES SUMMARY
The following table (table-22) presents a summary of the security
assurance process set of activities and the responsibility of each
stakeholder through each one.

Activity Entity Entity Entity

responsible for responsible for responsible for
performing the reviewing the auditing
activity activity and activity
update if outcomes
necessary

Risk Service Provider Service Provider NTRA Security

Assessment Staff
activity

Defining Service Provider Service Provider NTRA Security

High Level Staff
Controls

Conformity Service Provider Service Provider NTRA Security

Assessment Staff

Table-22: A summary of the security assurance process activities

and responsibility of stakeholders
84
 LIST OF TABLES AND FIGURES

LIST OF TABLES

Table-1 IoT Application Categorization.

Table-2 IoT attack surfaces, related vulnerabilities and its impact.

Table-3 Risk assessment matrix [5x5 example].

Risk levels and scores for risk assessment matrix described in

Table-4
table-2.

Table-5 Example of a simplified risk register.

Table-6 CIA Triad impact levels explained.

Security requirement classes for the IoT Cybersecurity

Table-7
framework.

Mapping security requirement classes to the CIA impact

Table-8
levels.

Table-9 List of security requirements categories and domains.

Table-
Device hardware and physical security Policies, and controls.
10

Table-
Device software Policies, and controls.
11

Table-
Device OS Policies, and controls.
12

85
Table- Device wireless and wired interfaces security Policies, and
13 controls.

Table- Device Authentication and Authorization Policies, and

14 controls.

Table- Encryption and key management security Policies, and

15 controls.

Table-
Cybersecurity state awareness Policies, and controls.
16

Table-
Web UI Policies, and controls.
17

Table-
Mobile application security Policies, and controls.
18

Table-
Cloud and Network elements security Policies, and controls.
19

Table-
Continuous assessment and monitor Policies, and controls.
20

Table-
Checklist response options.
21

Table- A summary of the security assurance process activities and

22 responsibility of stakeholders

LIST OF FIGURES

Figure-
IoT Application Classification.
1

Figure-
IoT Security assurance process activities.
2

86
Figure-
Risk Assessment Procedure.
3

Figure-
Defining Applicable High Level Security Controls Procedure.
4

Figure-
Conformity Assessment Procedure.
5

Figure-
Risk assessment main steps.
6

Figure-
Defining applicable high level security controls procedure.
7

Figure-
Conformity assessment procedure
8

87
REFERENCES
● European Telecommunications Standards Institute (ETSI) EN
303 645 V2.1.1 (2020-06) - Cyber Security for Consumer Internet
of Things: Baseline Requirements -
https://www.etsi.org/deliver/etsi_en/303600_303699/303645/0
2.01.01_60/en_303645v020101p.pdf
● UK Code of Practice for Consumer IoT Security - 2018 -
https://assets.publishing.service.gov.uk/government/uploads
/system/uploads/attachment_data/file/971440/Code_of_Pra
ctice_for_Consumer_IoT_Security_October_2018_V2.pdf

● Datta Burton, S.., Tanczer, L.M., Vasudevan, S., Hailes, S., Carr,
M. (2021). The UK Code of Practice for Consumer IoT Security:
‘where we are and what next’. The PETRAS National Centre of
Excellence for IoT Systems Cybersecurity. DOI:
10.14324/000.rp.10117734 -
https://assets.publishing.service.gov.uk/government/uploads
/system/uploads/attachment_data/file/978692/The_UK_cod
e_of_practice_for_consumer_IoT_security_-
_PETRAS_UCL_research_report.pdf

● IoTSF IoT Security Assurance Framework - Release-3.0-Nov-

2021-1.
● IoT Cybersecurity: Regulation Ready - Full Version - Nov 2018
https://www.iotsecurityfoundation.org/wp-
content/uploads/2018/11/IoT-Cybersecurity-Regulation-
Ready-White-Paper-Full-Version.pdf

● Secure Design Best Practice Guides - Nov 2019

https://www.iotsecurityfoundation.org/wp-
content/uploads/2019/12/Best-Practice-Guides-Release-
2_Digitalv3.pdf
● GSMA IoT Security Guidelines - Overview Document - Version
2.2 - 29 February 2020
https://www.gsma.com/iot/wp-
content/uploads/2020/05/CLP.11-v2.2-GSMA-IoT-Security-
Guidelines-Overview-Document.pdf

88
 ● The OWASP IoT Attack Surface Areas -
https://wiki.owasp.org/index.php/OWASP_Internet_of_Things
_Project#IoT_Attack_Surface_Areas

● The OWASP IoT Top Ten - Internet of things 2018

● CISA Internet of Things Acquisition Guidance

● The NIST Framework for Improving Critical Infrastructure

Cybersecurity -
https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.04162018.
pdf
● The NIST Special Publication 800-30r1 Guide for Conducting
Risk Assessments -
https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublic
ation800-30r1.pdf
● The NIST Special Publication 800-53Ar5 - Assessing Security and
Privacy Controls in Information Systems and Organizations -
https://doi.org/10.6028/NIST.SP.800-53r5
● IoT Device Security Standards & Code of Practice for IoT
Security - https://www.coderus.com/iot-device-security-
standards-and-code-of-practice-for-iot-security/
● Anand, P.; Singh, Y.; Selwal, A.; Singh, P.K.; Felseghi, R.A.;
Raboaca, M.S. IoVT: Internet of Vulnerable Things? Threat
Architecture, Attack Surfaces, and Vulnerabilities in Internet of
Things and Its Applications towards Smart Grids. Energies 2020,
13, 4813. https://doi.org/10.3390/en13184813

89
APPENDIX-A: CASE STUDY
This section is intended to show how to use the framework to secure
the IoT service provided by the service provider. It explains the
complete step by step process to determine the compliance of an
IoT service, and service provider to the cybersecurity framework.
Consider a practical example of a smart grid service provider who
offers an IoT connected smart electricity meter to the customers.
The smart meters communicate to the AMI backend system to
automatically send the readings and receive the commands from
the service provider. The network keeps personal information about
the clients since every meter is logically mapped to a specific client
at a specific location, and the network collects information about
the electricity consumption of the clients. These data are stored on
the data centers of the service provider for further procession. The
following process explained in figure-A-1 is needed to comply with
the framework.

Figure-A-1: The Cybersecurity Process for the IoT Cybersecurity

Framework for the case study

90
 1. Risk Assessment

1.1. Use case identification

The first step is defining the use cases of the provided service. The
use cases have to be end-to-end use cases since it would be used
later to determine the probable attack surfaces. The output is a list
including all the possible use cases, functionalities, expected
provided service. In this case study, a small sample for the use cases
is created in table-A-1 as an explanation of the required output.

Use
Ca Use Provided System
Functionality
se Case Service Components
ID
1. Smart meters to measure the
Gather Automati
power consumption.
ing c Smart meter.
2. Smart meters store the
readin readings LTE
consumption values securely
01 gs from submissio Communicati
on the device till transmission.
the n to the on modem.
3. Smart meters send the
smart service AMI Backend.
calculated readings to the AMI
meters provider
backend through LTE
Executi 1. Smart meters receive
Comman
ng commands from the AMI
d
comm backend based on the Smart meter.
executio
ands identity of every smart LTE
n based
02 from meter. Communicati
on the
the 2. Smart meter is able to on modem.
service
service execute the command. AMI Backend.
provider
provid 3. Smart meters report back
requests.
er the status to the AMI system.
Table-A-1: Use case identification of the case study.

1.2. Attack surface areas & impact identification

For every use case, determine all the possible attack surfaces and
the impacts on the system components and the provided service.
A sample analysis in table-A-2 is provided to explain the required
information in the output table.

91
Attack
Vulnerabilities Impact
Surface
Injecting backdoor
account on the smart
■ Sensitive data exposure (backdoor meter can lead to
accounts, hardcoded credentials, sending incorrect
encryption keys, sensitive readings and data to the
information). service provider which
■ Firmware version display and/or leads to:
Device
last update date. - Taking wrong
Firmware
■ Vulnerable services (web, ssh, tftp, decisions based on
etc.). false data
■ Security related function API - Financial loss to the
exposure. service provider
■ Firmware downgrade possibility. - Opening the door for
more attacks on the
device and network
Getting access to the
combination encryption
keys and parameters
■ Sensitive data
Device reveals the network data.
(Cleartext usernames, cleartext
Memory This results in a huge
passwords, encryption keys).
information leak including
personal information of
the customers.
Leaking personal user
■ User data disclosure information such as
Privacy ■ User/device location disclosure identity, address, and
■ Differential privacy consumption leads to
privacy violations.
Weak access controls
■ Inherent trust of cloud or mobile lead to injection attacks
application and account takeover
Vendor
■ Weak authentication attacks. This may lead to
Backend
■ Weak access controls taking control over the
APIs
■ Injection attacks meters in a specific area
■ Hidden services or a complete denial of
service.

92
Attack
Vulnerabilities Impact
Surface
■ Authentication/Authorization
related values (session key, token,
cookie, etc.) disclosure
■ Reusing of session key, token, etc.
Weak authentication
■ Device to device authentication
between the meter and
Authenticat ■ Device to mobile Application
backend leads to rogue
ion/ authentication
device attacks. This can
Authorizatio ■ Device to cloud system
lead to complete denial
n authentication
of service or taking control
■ Mobile application to cloud system
over the smart grid.
authentication
■ Web application to cloud system
authentication
■ Lack of dynamic authentication
Rogue updates sent to
■ Update sent without encryption
the smart grid network
■ Updates not signed
resulting in taking control
■ Update location writable
over the whole smart
Update ■ Update verification
meters network. May lead
Mechanism ■ Update authentication
to catastrophic results
■ Malicious update
such as power outage
■ Missing update mechanism
and faults in load
■ No manual update mechanism
balance.
■ Firmware extraction.
■ User CLI.
Ability to access the
■ Admin CLI.
device may lead to
■ Privilege escalation.
Device modifying sensitive data
■ Reset to an insecure state.
Physical such as encryption
■ Removal of storage media.
Interfaces parameters, and tariff. This
■ Tamper resistance.
leads to financial loss for
■ Debug port (UART (Serial), JTAG /
the service provider.
SWD).
■ Device ID/Serial number exposure.

Table-A-2: Attack surface identification of the case study, with

relevant vulnerabilities and its impact

93
 1.3. Risk Analysis and Evaluation:

Using the reference risk assessment matrix in table-A-3 determine

the overall risk for the exploitation of the attack surfaces depending
on the likelihood and the impact level.

Impact Level
Moderat Very
Very Low Low High
e High
Multiple
Negligibl Limited Serious Severe
severe
e effect effect effect effect
effects
Very Almost Moderat Very
Very Low Low High
High certain e High
Moderat Very
High Highly likely Very Low Low High
e High
Moderat Somewhat Moderat Moderat
Very Low Low High
Lik
eli

e likely e e
Moderat
Low Unlikely Very Low Low Low Low
e
Highly
Very Low Very Low Very Low Very Low Low Low
unlikely

Table-A-3: Risk assessment matrix of the case study

Then map the likelihood and impact to table-A-4 to get the overall
risk of every attack.

Risk level Risk Description

score

Very Low [0-4] Threat could be expected to have a negligible

effect.

Low [5-20] Threat could be expected to have a limited

effect.

Moderat [21-79] Threat could be expected to have a serious

e effect.

94
High [80-95] Threat could be expected to have a severe or
catastrophic effect.

Very High [95-100] Threat could be expected to have multiple

severe or catastrophic effects.

Table-A-4: Risk levels and scores for risk assessment matrix of the
case study

As a practical example, there is a very high probability that a

hacker would tamper with the physical interface of the meter, and
try to hack the physical interfaces such as UART, communication
buses,etc.. In addition, the impact of such an attack is very high
since it leads to multiple catastrophic effects on the network as
explained in the attack surface identification in table-A-2. This
means that the overall risk from such an attack is considered “very
high” and has a score of “95-100”.

1.4. Findings documentation [Risk register]

Results are documented in a risk register document. A sample for
the risk register is provided in table-A-5 for the smart meter use case.

Impact/Cost to
Probabilit
Threat company of threat Risk
y
Description happening Factor
(0-100%)
(0-5)
Tampering the physical
interface and taking (0.95*5)
95% 5
control over the smart = 4.75
meter
Exploiting update (0.1*4)
10% 4
mechanism =0.4
Breaking Authentication (0.1*4)
10% 4
Mechanisms = 0.4

Table-A-5: risk register for the case study.

95
 1.5. Risk analysis review & update

Finally, the risk scores, impacts, and likelihood is reviewed to check

if any additional modifications are needed before finishing
documenting the findings to a risk register document.
2. High Level Security Requirements

The process of the high-level security requirements is intended to

select the appropriate security class for the provided service which
matches the impact and size of the threats and risks on the
provided service. The process is explained in figure-A-2.

Figure-A-2: High level security requirements identification process.

2.1. Determine CIA Objectives

Based on the risk register document generated in the “Risk

Assessment” process, the impact of the overall threats on
confidentiality, integrity, and availability must be calculated
according to table-A-6.

Object Low Impact Moderate Impact High Impact

The unauthorized
The unauthorized
The unauthorized disclosure of
disclosure of
disclosure of information could
information could be
information could be be expected to
expected to have a
expected to have a have a severe or
Confidenti limited adverse
serious adverse effect catastrophic
ality effect on
on organizational adverse effect on
organizational
operations, organizational
operations,
organizational assets, operations,
organizational
or individuals. organizational
assets, or individuals.
assets, or individuals.
The unauthorized The unauthorized The unauthorized
Integrity
modification or modification or modification or

96
 destruction of destruction of destruction of
information could be information could be information could
expected to have a expected to have a be expected to
limited adverse serious adverse effect have a severe or
effect on on organizational catastrophic
organizational operations, adverse effect on
operations, organizational assets, organizational
organizational or individuals. operations,
assets, or individuals. organizational
assets, or individuals.
The disruption of
The disruption of The disruption of
access to or use of
access to or use of access to or use of
information or an
information or an information or an
information system
information system information system
could be expected
could be expected could be expected to
to have a severe or
Availability to have a limited have a serious adverse
catastrophic
adverse effect on effect on
adverse effect on
organizational organizational
organizational
operations, operations,
operations,
organizational organizational assets,
organizational
assets, or individuals. or individuals.
assets, or individuals.
Table-A-6: CIA Objective
As a practical example for the smart meter case study, the risk
register table-A-7 shows a very high impact and likelihood for the
physical tampering threat. The impact of this threat can be
mapped to the CIA as follows:

Confidentiality Integrity Availability

Moderate Impact High Impact
High impact
Unauthorized data Any DoS attack can cause a
Leaking sensitive
modification may lead complete power outage over
information about the
to serious damage to a large geographical area,
customers from the
the service provider, and may lead to faults in load
service provider
e.g., unauthorized balancing, explosions, and
database, and leaking
modification of the fires. These effects are
credentials, are all
Tariff. considered catastrophic on
considered
service providers, clients, and
catastrophic effects on
the whole country.

97
the service provider
and clients
Table-A-7: Impact of threat on the CIA objectives regarding the
case study

2.2. Determine the Security Class

In this step, the output CIA impact is used to determine the correct
security class for the provided service. In this case study, it is clear
that the output is “Class 3” security requirements and controls.
2.3. Determine Applicable Security Class Controls
Finally, all controls and requirements marked as the following:
1. Mandatory for class 3 and above.

2. Mandatory for class 2 and above.

3. Mandatory for class 1 and above.
4. Mandatory for all classes.

are all mandatory requirements to be applied to the service

providing organization, and the technical service, devices, and
software provided to the customers.
3. Conformity Assessment
This is the final step in the process where the service provider
answers all the questionnaires which determines the conformity of
the service providing organization, and the technical service to the
cybersecurity framework. If the service provider, or the provided
service is fully/partially compliant with the cybersecurity framework,
evidence must be provided to strengthen this claim. If the controls
are not applicable for the service or the service is not compliant, a
reason must be provided.
After the service provider fills the questionnaire document with the
required input, the audit and review process from the NTRA starts to
determine if both the service providing organization and the

98
provided technical service are compliant with the cybersecurity
framework.

99
APPENDIX-B: DISCLAIMER
FOR NON CRITICAL INFRASTRUCTURE IOT APPLICATIONS
The IoT Solution User/Provider signing below is responsible for
execution and confidentiality of all information described in this
document.

The information contained within this report is considered

confidential and while the NTRA strives to keep the information
confidential and correct, therefore any inappropriate or
unauthorized disclosure of this report or portions of it could result in
significant damage or loss.
Since the IoT solution under review is not used by any governmental
or critical infrastructure sectors, therefore it can be accredited only
on the condition of providing a signed document by the solution’s
user/provider assuring and stating that the NTRA disclaims any
responsibility for any cyber-security risks or vulnerabilities regarding
this solution. And in case of deciding to re-sell or re-distribute this
solution for any of the governmental or critical infrastructure sectors
(as described by the executive regulations of law no.175 of 2018
and the NTRA’s IoT Framework in the ARE), then this disclaimer will
not be valid anymore on that case, and the solution’s user/provider
must first acquire the NTRA’s permission. Otherwise, they shall be
considered accountable and responsible according to the law
no.175 of 2018 regarding Combating information technology
crimes. Paper copies should be locked up when not in use.
Electronic copies should be stored offline and protected
appropriately.

Responsible Person
IoT Solution User/Provider
…………………………….
Date: ………………………

100