ETSI TR 103 534-1 V1.1.1 (2019-08)

SmartM2M; Teaching material; Part 1: Security

DTR/SmartM2M-103534-1

General Information

• Status: Published
• Publication Date: 26-Aug-2019
• Technical Committee: SmartM2M - Smart M2M
• Current Stage: 12 - Completion
• Due Date: 30-Aug-2019
• Completion Date: 27-Aug-2019

Standards Content (Sample)

TECHNICAL REPORT
SmartM2M;
Teaching material;
Part 1: Security

2 ETSI TR 103 534-1 V1.1.1 (2019-08)

Reference
DTR/SmartM2M-103534-1
Keywords
cybersecurity, IoT, oneM2M
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2019.
All rights reserved.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.

3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and
of the oneM2M Partners. ®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
3 ETSI TR 103 534-1 V1.1.1 (2019-08)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
1 Scope . 6
1.1 Context for the present document . 6
1.2 Scope of the present document . 6
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 7
3 Definition of terms, symbols and abbreviations . 8
3.1 Terms . 8
3.2 Symbols . 8
3.3 Abbreviations . 8
4 What is Security? . 9
4.1 Introduction and overview . 9
4.2 Teaching goals . 10
4.3 Learning goals . 10
5 Security in the context of IoT . 10
5.1 A global approach to IoT Systems . 10
5.1.1 Major characteristics of IoT systems . 10
5.1.2 The need for an "IoT-centric" view . 11
5.1.2.1 Introduction . 11
5.1.2.2 Roles . 11
5.1.2.3 Reference Architecture(s) . 11
5.1.2.4 Guidelines . 11
6 Overview of IoT security challenge . 11
6.1 The challenge . 11
6.2 Conventions and terminology. 12
6.3 Trust and roots of trust . 13
6.4 The CIA paradigm . 13
6.5 Review of landscape and best practices . 14
6.6 Rationale for training and education in IoT security . 14
7 Security use cases . 15
Annex A: Threat, Vulnerability and Risk Analysis in IoT . 16
A.1 Role of TVRA . 16
A.2 Identification of IoT Security environment . 16
A.3 Modelling of threats and vulnerabilities . 17
A.4 Determination of risk. 18
A.5 Monitoring of threat level. 18
A.6 Determination of applicable countermeasures . 18
A.7 Revision, verification and validation . 19
Annex B: Applying best practices to IoT security. 20
Annex C: Cryptographic security basics . 22
C.1 Role of cryptography in security . 22
ETSI
4 ETSI TR 103 534-1 V1.1.1 (2019-08)
C.2 Historic roots of cryptography . 22
C.3 Relationship identification to pre-select cryptographic architecture . 24
C.4 Core cryptographic modes . 24
Annex D: Secure configuration of IoT devices . 25
Annex E: Secure operation of IoT devices . 26
Annex F: Programming guide for secure IoT . 27
F.1 Overview . 27
F.2 Data passing issues . 27
F.3 Memory allocation issues . 28
F.4 Memory leakage issues . 28
F.5 Data type issues . 29
F.6 SQL injection and database management issues . 29
Annex G: Guide to selecting a training provider. 32
G.1 Overview . 32
G.2 Certified Information Systems Security Professional (CISSP) . 32
G.3 Cyber Security & Governance Certification Program . 32
G.4 CompTIA Advanced Security Practitioner (CASP) . 32
G.5 Systems Security Certified Practitioner . 32
G.6 DevSecOps . 33
Annex H: Change History . 34
History . 35

ETSI
5 ETSI TR 103 534-1 V1.1.1 (2019-08)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Foreword
This Technical Report (TR) has been produced by ETSI Technical Committee Smart Machine-to-Machine
communications (SmartM2M).
The present document is part 1 of a multi-part deliverable covering SmartM2M Training Material, as identified below:
Part 1: "Security";
Part 2: "Privacy".
Modal verbs terminology
In the present document "should", "should not", "may", "need not", "will", "will not", "can" and "cannot" are to be
interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.

ETSI
6 ETSI TR 103 534-1 V1.1.1 (2019-08)
1 Scope
1.1 Context for the present document
The design, development and deployment of - potentially large - IoT systems require to address a number of topics -
such as privacy, interoperability or security - that are related and should be treated in a concerted manner. In this
context, several Technical Reports have been developed that each address a specific facet of IoT systems.
In order to provide a global a coherent view of all the topics addressed, a common approach has been outlined across
the the present document concerned with the objective to ensure that the requirements and specificities of the IoT
systems are properly addressed and that the overall results are coherent and complementary.
The present document has been built with this common approach also applied in all of the other documents listed
below:
ETSI TR 103 533 [i.1]
ETSI TR 103 534 [i.15]
NOTE: ETSI TR 103 534-1 is the present document
ETSI TR 103 535 [i.3]
ETSI TR 103 536 [i.4]
ETSI TR 103 537 [i.5]
ETSI TR 103 591 [i.19]
1.2 Scope of the present document
The present document presents teaching material to allow readers, identified by role, to gain knowledge of the
fundamentals of IoT security.
The present document is structured as a set of annexes each containing the outline of training material. The more
detailed training material, in the form of a set of PowerPoint slides is provided in archive tr_10353401v010101p0.zip
as an electronic addition to the present document.
The annexes contain training material in the following areas:
• Threat, Vulnerability and Risk Analysis (TVRA) in IoT:
- The role of TVRA is primarily to ensure that a system is designed and deployed with a thorough
understanding of the environment in which it will be deployed, the purpose of the system, the
components or assets of the system, the links between the deployment and its environment, and the
technical/procedural/regulatory basis of the system. Having this core understanding alongside an analysis
of the threats and threat agents that will seek to attack the system leads to an understanding of the risks to
the system.
- The material in this clause extends from material prepared for the ETSI TVRA Workshop (March 2009)
and is based on the TVRA method published in ETSI TS 102 165-1 [i.2] with specific IoT use cases to
drive the TVRA exercise.
• Secure configuration of IoT devices:
- The vast majority of security failures occur as a result of poor configuration. For example reliance on
default security attributes (the default password conundrum). The purpose of this module is to give
guidance on how to securely configure IoT devices to minimise their attack surface.
ETSI
7 ETSI TR 103 534-1 V1.1.1 (2019-08)
• Cryptographic security basics as they apply in IoT:
- Cryptography is the mathematical toolset that underpins the majority of countermeasures (i.e.
authentication, encryption, integrity proof and verification). The purpose of this module is to give a
simple grounding in the role and purpose, and the underlying mechanisms of cryptography. Amongst the
topics to be covered are the following:
 Role of cryptography in security
 Historic roots of cryptography
 Relationship identification to pre-select cryptographic architecture
 Core cryptographic modes
- The material provides examples based on AES as published in FIPS 197 [i.11] and the Diffie Hellman
asymmetric key exchange protocol.
• Secure operation of IoT devices:
- Closely related to secure configuration is secure operation and this module addresses the measures
required to assure that a securely configured device can be operated securely.
• Applying best practices to IoT security:
- The purpose of this module is to give specific training in how to apply the best practices identified in
ETSI TR 103 533 [i.1] to real IoT systems.
• Programming guide for secure IoT:
- The purpose of this module is to give guidance on secure or safe programming. By means of coding
examples (in programming languages including Swift, C, C++, Java) the steps to minimise security flaws
in programming of IoT devices.
• Guide to selecting a training provider:
- A guide to the identification and selection of training providers and training programmes in IoT.
2 References
2.1 Normative references
Normative references are not applicable in the present document.
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI TR 103 533: "SmartM2M; Security; Standards Landscape and best practices".
[i.2] ETSI TS 102 165-1: "CYBER; Methods and protocols; Part 1: Method and pro forma for Threat,
Vulnerability, Risk Analysis (TVRA)".
ETSI
8 ETSI TR 103 534-1 V1.1.1 (2019-08)
[i.3] ETSI TR 103 535 (V1.1.1): "SmartM2M; Guidelines for using semantic interoperability in the
industry".
[i.4] ETSI TR 103 536: "SmartM2M; Strategic / technical approach on how to achieve
interoperability/interworking of existing standardized IoT Platforms".
[i.5] ETSI TR 103 537: "SmartM2M; Plugtests™ preparation on Semantic Interoperability".
[i.6] ETSI TR 103 591: "SmartM2M; Privacy study report; Standards Landscape and best practices".
[i.7] AIOTI: "High Level Architecture (HLA)", Release 4.0, June 2018.
[i.8] ENISA: "IoT Security Standards Gap Analysis", ISBN: 978-92-9204-275-2, DOI:
10.2824/713380.
[i.9] Regulation (EU) 2019/881 of the European Parliament and of the Council of 17 April 2019 on
ENISA (the European Union Agency for Cybersecurity) and on information and communications
technology cybersecurity certification and repealing Regulation (EU) No 526/2013 (Cybersecurity
Act).
[i.10] ETSI TS 103 645: "CYBER; Cyber Security for Consumer Internet of Things".
[i.11] National Institute of Standards and Technology (NIST) FIPS 197: "Federal Information Processing
Standards Publication 197; Advanced Encryption Standard (AES)", November 26, 2001.
[i.12] GSMA IoT Security Guidelines and IoT Security Assessment.
NOTE: Available from https://www.gsma.com/iot/iot-security/iot-security-guidelines/
[i.13] ETSI TR 103 305-1: "CYBER; Critical Security Controls for Effective Cyber Defence; Part 1: The
Critical Security Controls".
[i.14] ETSI TR 103 534: "SmartM2M; Teaching Material: Part 1 (Security) and Part 2 (Privacy)".
NOTE: ETSI TR 103 534-1 is the present document.
[i.15] ETSI EN 300 392-7: "Terrestrial Trunked Radio (TETRA); Voice plus Data (V+D); Part 7:
Security".
3 Definition of terms, symbols and abbreviations
3.1 Terms
Void.
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AES Advanced Encryption Standard
AIOTI The Alliance for Internet of Things Innovation
API Application Programming Interface
CASP CompTIA Advanced Security Practitioner
CIA Confidentiality, Integrity, Availability
CISSP Certified Information Systems Security Professional
DB DataBase
ETSI
9 ETSI TR 103 534-1 V1.1.1 (2019-08)
DBA DataBase Administator
DBMS DataBase Management System
DDoS Distributed Denial of Service
DevOps Development IT Operations
DevSecOps Secure DevOps
DNS Domain Name System
DoS Denial of Service
e-CF European e-Competence Framework
ENISA European Union Agency for Network and Information Security
ERP Enterprise Resource Planning
ESAPI OWASP Enterprise Security API
ETSI European Telecommunication Standards Institute
FIPS Federal Information Processing Standard
GDPR General Data Protection Regulation
GSMA GSM Association
IaC Infrastructure as Code
ICT Information and Communications Technology
IoT Internet of Things
ISC International Information System Security Certification Consortium
IT Information Technology
ORM Object Relational Mapper
OS Operating System
OWASP Open Web Application Security Project
RSA Rivest Shamir Aldeman
SQL Structured Query Language
SSCP Systems Security Certified Practitioner
TOE Target Of Evaluation
TR Technical Report
TVRA Threat, Vulnerability and Risk Analysis
4 What is Security?
4.1 Introduction and overview
The question "What is Security?" is very difficult to answer succinctly. In the context of ICT, security is often taken to
refer to the prevention of various forms of attack on the system, or elements of the system. The purpose of the present
document, as indicated in the Scope statement, is to provide material to allow readers, identified by role, to gain
knowledge of the fundamentals of IoT security.
Whilst these concepts are expanded upon in the remainder of the present document the complexity of "security" as a
topic to understand is highlighted by the many roles and process that "security" has to tackle:
• System protection role:
- Core CIA roles - least knowledge model to assure system operation.
- Analytic role - data required to forecast, resolve, recover.
• Anti-adversary role:
- Identify who gains from system breaches.
• Risk management role:
• Regulatory compliance role:
- Assurance of technical provisions for GDPR, for the Cyber-Security directive, for law enforcement, for
support of the eIDAS regulation and so forth.
A reasonable level of understanding of each of these roles, and the technologies and processes that enable them, is the
ultimate goal of the present document.
ETSI
10 ETSI TR 103 534-1 V1.1.1 (2019-08)
4.2 Teaching goals
The bulk of the material in the present document is aimed at tutor led teaching and there is a presumption of prior
knowledge to apply the material to the actual audience. Thus there are hints given at points in the material for the
tutor/teacher to drive classroom exercises. Such exercises are not definitive in that there is no implied certificate or
other statement of learning from the material but are intended to allow the tutor to assess the success of students in
assimilating the material offered.
NOTE: In the case of tutor lead classwork the tutor is expected to expand upon the base material that is provided
in the present document and its attachments as required by the students.
4.3 Learning goals
Whilst not specifically designed for self-tutoring when used in such a context, as for teaching goals, the present
document has some specific learning goals when acting as the basis of self-taught material. Specific learning goals are
indicated at the start of each clause in order to guide the reader as to the new knowledge that will be gained after
completion of the material in each clause.
5 Security in the context of IoT
5.1 A global approach to IoT Systems
5.1.1 Major characteristics of IoT systems
IoT systems are often seen as an extension to existing systems needed because of the (potentially massive) addition of
networked devices. However, this approach does not take stock of a set of essential characteristics of IoT systems that
push for an alternative approach where the IoT system is at the centre of attention of those who want to make them
happen. This advocates for an "IoT-centric" view.
Most of the above-mentioned essential characteristics may be found in other ICT-based systems. However, the main
difference with IoT systems is that they all have to be dealt with simultaneously. The most essential ones are:
• Stakeholders. There is a large variety of potential stakeholders with a wide range of roles that shape the way
each of them can be considered in the IoT system. Moreover, none of them can be ignored.
• Privacy. In the case of IoT systems that deal with critical data in critical applications (e.g. e-Health, Intelligent
Transport, Food, Industrial systems), privacy becomes a make or break property.
• Interoperability. There are very strong interoperability requirements because of the need to provide seamless
interoperability across many different systems, sub-systems, devices, etc.
• Security. As an essential enabling property for Trust, security is a key feature of all IoT systems and needs to
be dealt with in a global manner. One key challenge is that it is involving a variety of users in a variety of use
cases.
• Technologies. By nature, all IoT systems have to integrate potentially very diverse technologies, very often for
the same purpose (with a risk of overlap). The balance between proprietary and standardised solutions has to
be carefully managed, with a lot of potential implications on the choice of the supporting platforms.
• Deployment. A key aspect of IoT systems is that they emerge at the very same time where Cloud Computing
and Edge Computing have become mainstream technologies. All IoT systems have to deal with the need to
support both Cloud-based and Edge-based deployments with the associated challenges of management of data,
etc.
• Legacy. Many IoT systems have to deal with legacy (e.g. existing connectivity, back-end ERP systems). The
challenge is to deal with these requirements without compromising the "IoT centric" approach.
ETSI
11 ETSI TR 103 534-1 V1.1.1 (2019-08)
5.1.2 The need for an "IoT-centric" view
5.1.2.1 Introduction
In support of an "IoT-centric "approach, some elements have been used in the present document in order to:
• Support the analysis of the requirements, use cases and technology choices (in particular related to
interoperability).
• Ensure that the target audience can benefit from recommendations adapted to their needs.
5.1.2.2 Roles
A drawback of many current approaches to system development is a focus on the technical solutions, which may lead to
suboptimal or even ineffective systems. In the case of IoT systems, a very large variety of potential stakeholders are
involved, each coming with specific - and potentially conflicting - requirements and expectations. Their elicitation
requires that the precise definition of roles that can be related to in the analysis of the requirements, of the use cases, etc.
Examples of such roles to be characterised and analysed are: System Designer, System Developer, System Deployer,
End-user, Device Manufacturer. Some of these roles are specifically addressed in the present document.
5.1.2.3 Reference Architecture(s)
In order to better achieve interoperability, many elements (e.g. vocabularies, definitions, models) have to be defined,
agreed and shared by the IoT stakeholders. This can ensure a common understanding across them of the concepts used
for the IoT system definition. They also are a preamble to standardisation. Moreover, the need to be able to deal with a
great variety of IoT systems architectures, it is also necessary to adopt Reference Architectures, in particular Functional
Architectures. The AIOTI High-Level Architecture (see [i.7]) is the reference for the present document.
5.1.2.4 Guidelines
The very large span of requirements, Use Cases and roles within an IoT system make it difficult to provide prototypical
solutions applicable to all of the various issues addressed. The approach taken in the present document is to outline
some solutions but also to provide guidelines on how they can be used depending on the target audience. Such
guidelines are associated to the relevant roles and provide support for the decision-making.
6 Overview of IoT security challenge
6.1 The challenge
The core challenge in IoT, particularly embedded IoT where devices are often of an "enable and forget" form, is to
recognise that as an IoT device has processing and communication capacity, that often can be programmed post-
shipment, that it is a vector to attack any of the user, the system or something in the wider connected network. This
entails understanding of the management of risk through management of impact (if something happens) and
management of likelihood (of something happening). These aspects, impact and likelihood of an attack, have been at
the core of security engineering since its inception. The set of things that engineers are able to do to minimise risk are
considerable and part of the challenge in IoT is to provide a minimum set of technical capabilities that maximise the
security of the system. However even with the appropriate technology in place it is still necessary to have the non-
technology aspects correctly implemented and this means distribution chains, physical security measures, personnel
measures and so forth.
The primary security provisioning strategies of redesign or hardening are consistent with the goal of security design to
ensure a low likelihood of an unwanted incident arising. As the likelihood of an unwanted incident is dependent upon
the presence of weakness in an asset and also the presence of both threats and threat agents that exploit the weakness it
is the purpose of security systems to remove, or mask, the weaknesses of an asset.
ETSI
12 ETSI TR 103 534-1 V1.1.1 (2019-08)
• Asset redesign:
- The assumption made prior to analysis is that all assets have weaknesses and the job of the analyst is to
identify those weaknesses. Where weaknesses are found and have a large number of associated threats
and threat agents there may be a possibility to redesign the asset in such a way as to remove the inherent
weaknesses. The viability of this strategy will depend on a number of factors including the maturity of
the asset design and the relative cost of redesign versus the cost of weakness masking through asset
hardening.
• Asset hardening:
- An asset may have some weaknesses that cannot be removed but which may be masked or made
inaccessible by the addition of additional features or capabilities to the vulnerable asset or other assets in
the system such that the combination of assets in the system presents a lower likelihood of attack, and
hence a lower risk to the system.
EXAMPLE: A firewall is a classical asset hardening technique in that it does not alter the system behind the
wall but makes the asset or system hard to get to as the attacker first has to get past the wall.
6.2 Conventions and terminology
Security documents, and the engineers and designers, often use a distinctive terminology. The primary stakeholders are
given names: Alice, Bob and Eve. Alice and Bob are the parties to a secure transaction, so in general terms Alice is
trying to establish a relationship with Bob. Eve is the generalised adversary, whose purpose is to attack the relationship
between Alice and Bob.
One of the common models is to consider security in broad terms as determination of the triplet {threat, security-
dimension, countermeasure} such that a triple such as {interception, confidentiality, encryption} is formed. The threat
in this case being interception which risks the confidentiality of communication, and to which the recommended
countermeasure is encryption. More detail discussion of the security dimensions is given below. However, the nature of
threats needs greater examination. Threats can be gathered into several families:
• Masquerade: In this case Eve attempts to impersonate Bob such that Alice will interact with Eve in the belief
that she is talking to Bob. Masquerade attacks are most often countered by the use of authentication schemes.
• Manipulation: In this case Eve attempts to modify data that Alice is trying to access (generally given to Alice
by Bob). Examples include falsifying location, falsifying an account balance, introducing malicious code to an
application. Countering manipulation is often difficult but includes the use of cryptographic checksums, error
detection and correction codes, digital signatures. The security problem is to ensure that identification and
proof of manipulation cannot be manipulated too.
• Interception: In this case Bob is sending something to Alice and Eve views it in transit. Conventionally
interception threats are countered by encryption (in which case Eve can see that communication exists between
Alice and Bob but is unable to see the content of that communication).
• Theft: The theft attack extends the interception attack in that whilst Eve not only observes the communication
between Alice and Bob she may also intercept and redirect such that Alice never receives the data, or copies
the data such that whilst Alice receives the data Eve also has the data. The means to counter theft include
various forms of access control, encryption (if data is stolen it cannot be read), manipulation control including
things such as proof of source (if stolen data is re-presented this uses techniques that can reveal it does not
actually belong to the presenting party).
A further set of terms in security relate to the nature of an attack. Attacks can be direct, but can also be indirect. A direct
attack is just that, Eve directly attacks Alice or Bob or the link between them. However, Eve can also attack Alice, Bob
or their relation by attacking something else altogether, these are termed side-channel attacks. For example in the
internet there are several tools and protocols used to ensure that Alice and Bob can connect, so Eve can attack one of
those tools or protocols and prevent Bob from ever being able to attach to Alice, this could be achieved by poisoning
the DNS system, or attacking the network in such a way that valid traffic never reaches Alice (a Denial of Service
(DoS) attack, or a Distributed Denial of Service (DDoS) attack).
ETSI
13 ETSI TR 103 534-1 V1.1.1 (2019-08)
In addition to attacks against device function there are a class of attacks that use devices owned by Alice to act as
adversaries on behalf of Eve.Commonly these are referred to as "Trojan" devices, in reference to the myth of the gift of
the wooden horse from the Greeks to the people of Troy containing a hidden cadre of Greek soldiers who when inside
the city launched an attack (in other words an apparently benign package contains a hidden payload used to attack the
host).
6.3 Trust and roots of trust
Security mechanisms and procedures are predicated on some form of trust. There is equivalence in the real world of
course: Alice trusts the bank to store her money and to make it available on demand; Alice trusts that the bank will not
lose her money. The reasons that Alice trusts her bank are not always explicit but are a combination of peer review and
peer experience, of knowledge that banks are overseen by a regulatory authority, of independent reviews.
In the security domain the concept of trust is complex and multi-tiered. For an analogy to examine the levels of
complexity the use case or example considers that Alice is travelling across town to make a deposit of cash (very large
amount) in her bank. As cash is a highly desirable and easy to dispose of item it is attractive to thieves to steal, so Alice
will take steps to not-advertise that she is carry a lot of cash. She will also take steps to know exactly the form in which
she is carrying the cash, e.g. the denomination of each note and the number of each note, and she will keep this record
separate from the cash itself. Alice has to trust that the cash she is carrying is legitimate so she trusts that she has
received them from a reputable source. If Alice has a small window of time to take the cash to the bank she has to trust
her transport. In choosing transport she has to make a number of decisions regarding speed of transfer, safety of
transfer, cost of transfer, and exposure during transfer to Eve. Alice may choose public transport, or private transport,
she may choose to walk, to cycle, to drive. Each of these offers a different level of risk and places the cash she is
transferring at a different level of risk too. In determining which transport option to select Alice has to determine which
she trusts most to get her to the bank in time with lowest risk to the cash she is carrying. It would be easy to
continuously extend the scenario and in a teaching context the teacher is recommended to perform a brainstorming
exercise with the class to tease out the trust relationships that Alice has to maintain in the overall process of taking cash
from home to safely depositing it in the care of the bank.
Teaching exercise: Get students to build a map of the trust relationships for the scenario, and to then explain the risks
in terms of Eve and the residual risk accepted by Alice.
6.4 The CIA paradigm
Notwithstanding the discussion across ETSI TR 103 533 [i.1] the purpose of security technologies is multi-fold:
• Confidentiality: Information shared by Alice with Bob is only visible to Bob and Alice. If Eve can access the
information she cannot ascertain the meaning of the content. Primarily achieved using encryption.
rd
• Integrity: Information shared by Alice with Bob can be proven by Alice not to have been manipulated by a 3
party (Eve). Bob can verify this is the case. Primarily achieved using hash functions with have specific
characteristics.
• Availability: This addresses the aim of ensuring that an authorized party (i.e. Alice) is able to access services
or information when needed. In other words, that Alice has access only to those assets she is allowed to access
and that they are available to Alice when legitimately demanded, and that an adversary, Eve, does not have
access. The technologies that address this include Identity Management, Authentication and Access Control, in
addition considerations in the availability domain include reliability and resilience which, whilst not strictly
addressed by security technology, impact on availability.
One of the many characteristics of IoT is that the number of communicating entities is very large and the number of
possible relationships per device is larger than, say, cellular telecommunication where in effect the mobile device
connects to a trusted network using credentials held by their home, trusted, service provider.
ETSI
14 ETSI TR 103 534-1 V1.1.1 (2019-08)
As a trivial example it can be imagined that IoT communications security is equivalent to sending presents to
somebody. To ensure the recipient does not know the content before unwrapping, the sender masks the content by
wrapping the gift - this makes the content confidential. The intended recipient is clearly indicated on the label as is the
sender - this identifies the parties to the transaction and depending on how names are written may confer some proof of
identity. Finally, in order to ensure the package is not damaged the sender adds packaging that protects it - this is some
means of ensuring the integrity of the package is maintained in transit. Translating this to IoT data from A to B the data
can be encrypted to confer confidentiality, the parties A and B have to be able to prove their identity to confer
authenticity to the exchange, and the parties can add data to the package that will be used to assure and verify the
integrity of the package.
There are a number of complexities in IoT that arise from the nature and number of both devices and connections. The
most obvious of these is key management.
6.5 Review of landscape and best practices
A summary before consideration of using any security guidance or best practice is to reflect on the purpose of security
technologies and processes.
• System protection role:
- Core CIA roles - least knowledge model to assure system operation.
- Analytic role - data required to forecast, resolve, recover.
• Anti-adversary role:
- Identify who gains from system breaches.
• Risk management role.
• Regulatory compliance role:
- Assurance of technical provisions for GDPR, for Cyber-Security directive, for law enforcement, etc.
In looking at best practice addressed to non-security professionals, e.g. to developers to ensure that they have designed
the necessary capability (the power or ability to do something) and functionality (the quality of being suited to serve a
purpose well) into their products and services, to managers to ensure they have recruited the necessary expertise, to
users to ensure they maximise the available features of their devices, the guidance and best practices have to address
some or all of the roles in the foregoing list. Guidelines and best practices should be written in such a way that they
recognise the overlap of each of the roles. For example in looking at guidance that limits the attack surface exposed to
an adversary (anti-adversary role) it is necessary to consider guidance on how to achieve proof of who is acting in the
system (system protection and CIA roles) but as this may have an impact on regulatory compliance the guidance in that
role needs to be considered, also if data is required to protect the system by analysis of how the system is used then the
guidelines for system protection by analytics needs to be taken into account.
6.6 Rationale for training and education in IoT security
The ENISA gap analysis [i.8] identified a significant gap in the understanding of security and its application to systems.
The present document and its included training material is one means of addressing that perceived gap. However a
further strong message, made in ETSI TR 103 533 [i.1], is that whilst in many fields there is an ability to learn "on the
job", for security there is no such luxury. A danger that is not expressed in
...