draft tr 103 534-1v006 consultation · etsi 2 etsi tr 103 534 -1 v0.0.6 (2019 -03) 0 1 2 reference...
TRANSCRIPT
ETSI TR 103 534-1 V0.0.6 (2019-03)
SmartM2M; Teaching Material;
Part 1: Security
TECHNICAL REPORT
ETSI
ETSI TR 103 534-1 V0.0.6 (2019-03)2
0
1
2 Reference
DTR/SmartM2M-103534-1
Keywords
Cybersecurity; IoT; oneM2M
ETSI
650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
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 only prevailing document is the print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
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.
DECTTM, PLUGTESTSTM, UMTSTM and the ETSI logo are trademarks of ETSI registered for the benefit of its Members. 3GPPTM and LTETM are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners. oneM2M logo is protected for the benefit of its Members.
GSM® and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
ETSI TR 103 534-1 V0.0.6 (2019-03)3
Contents 3
Intellectual Property Rights ........................................................................................................................... 5 4
Foreword ...................................................................................................................................................... 5 5
Modal verbs terminology .............................................................................................................................. 5 6
Executive summary ...................................................................................................................................... 5 7
Introduction .................................................................................................................................................. 5 8
1 Scope .................................................................................................................................................. 6 9
1.1 Context for the present document ................................................................................................................. 6 10
1.2 Scope of the present document ..................................................................................................................... 6 11
2 References .......................................................................................................................................... 7 12
2.1 Normative references ................................................................................................................................... 7 13
2.2 Informative references .................................................................................................................................. 7 14
3 Definitions, symbols and abbreviations ............................................................................................... 8 15
3.1 Definitions ................................................................................................................................................... 8 16
3.2 Symbols ....................................................................................................................................................... 8 17
3.3 Abbreviations............................................................................................................................................... 8 18
4 What is Security? ................................................................................................................................ 9 19
4.1 Introduction and overview ............................................................................................................................ 9 20
4.2 Teaching goals ............................................................................................................................................. 9 21 4.3 Learning goals ............................................................................................................................................. 9 22
5 Security in the context of IoT .............................................................................................................. 9 23
5.1 A global approach to IoT Systems ................................................................................................................ 9 24
5.1.1 Major characteristics of IoT systems ....................................................................................................... 9 25
5.1.2 The need for an "IoT-centric" view ....................................................................................................... 10 26
5.1.2.1 Introduction..................................................................................................................................... 10 27
5.1.2.2 Roles ............................................................................................................................................... 10 28
5.1.2.3 Reference Architecture(s) ................................................................................................................ 10 29
5.1.2.4 Guidelines ....................................................................................................................................... 10 30
6 Overview of IoT security challenge ................................................................................................... 11 31
6.1 The challenge ............................................................................................................................................. 11 32
6.2 Conventions and terminology ..................................................................................................................... 11 33
6.3 Trust and roots of trust ............................................................................................................................... 11 34
6.4 The CIA paradigm ..................................................................................................................................... 12 35
6.5 Review of landscape and best practices....................................................................................................... 12 36
6.6 Rationale for training and education in IoT security .................................................................................... 13 37
7 Security use cases ............................................................................................................................. 13 38
Annex A: Threat, Vulnerability and Risk Analysis in IoT ...................................................................... 15 39
A.1 Role of TVRA .................................................................................................................................. 15 40
A.2 Identification of IoT Security environment ........................................................................................ 15 41
A.3 Modelling of threats and vulnerabilities ............................................................................................. 16 42
A.4 Determination of risk ........................................................................................................................ 16 43
A.5 Monitoring of threat level ................................................................................................................. 16 44
A.6 Determination of applicable countermeasures .................................................................................... 16 45
A.7 Revision, verification and validation ................................................................................................. 16 46
Annex B: Applying best practices to IoT security ................................................................................... 17 47
Annex C: Cryptographic security basics.................................................................................................. 19 48
ETSI
ETSI TR 103 534-1 V0.0.6 (2019-03)4
C.1 Role of cryptography in security ....................................................................................................... 19 49
C.2 Historic roots of cryptography ........................................................................................................... 19 50
C.3 Relationship identification to pre-select cryptographic architecture.................................................... 19 51
C.4 Core cryptographic modes................................................................................................................. 19 52
Annex D: Secure configuration of IoT devices ......................................................................................... 20 53
Annex E: Secure operation of IoT devices ............................................................................................... 24 54
Annex F: Programming guide for secure IoT .......................................................................................... 28 55
F.1 Overview .......................................................................................................................................... 28 56
F.2 Data passing issues ........................................................................................................................... 28 57
F.3 Memory allocation issues .................................................................................................................. 28 58
F.4 Data type issues ................................................................................................................................ 28 59
Annex G: Guide to selecting a training provider ..................................................................................... 29 60
G.1 Overview .......................................................................................................................................... 29 61
G.2 Certified Information Systems Security Professional (CISSP) ........................................................... 29 62
G.3 Cyber Security & Governance Certification Program ........................................................................ 29 63
G.4 CompTIA Advanced Security Practitioner (CASP) ........................................................................... 30 64
G.5 Systems Security Certified Practitioner ............................................................................................. 30 65
G.6 DevSecOps ....................................................................................................................................... 30 66
Annex : Bibliography ................................................................................................................................ 31 67
Annex : Change History ........................................................................................................................... 32 68
History ....................................................................................................................................................... 33 69
70
71
ETSI
ETSI TR 103 534-1 V0.0.6 (2019-03)5
Intellectual Property Rights 72
Essential patents 73
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information 74
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 75
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 76
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 77
server (https://ipr.etsi.org). 78
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 79
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 80
server) which are, or may be, or may become, essential to the present document. 81
Trademarks 82
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners. 83
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no 84
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does 85
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks. 86
Foreword 87
This Technical Report (TR) has been produced by ETSI Technical Committee SmartM2M. 88
Modal verbs terminology 89
In the present document "should", "should not", "may", "need not", "will", "will not", "can" and "cannot" are to be 90 interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions). 91
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation. 92
Executive summary 93
94
Introduction 95
96
97
ETSI
ETSI TR 103 534-1 V0.0.6 (2019-03)6
1 Scope 98
1.1 Context for the present document 99
The design, development and deployment of – potentially large – IoT systems require to address a number of topics - 100
such as privacy, interoperability or security - that are related and should be treated in a concerted manner. In this 101
context, several Technical Reports have been developed that each address a specific facet of IoT systems. 102
In order to provide a global a coherent view of all the topics addressed, a common approach has been outlined across 103
the Technical Reports concerned with the objective to ensure that the requirements and specificities of the IoT systems 104
are properly addressed and that the overall results are coherent and complementary. 105
The present document has been built with this common approach also applied in all of the other documents listed 106 below: 107
TR 103 533 Security; Standards Landscape and best practices 108
TR 103 534 Teaching Material: Part 1 (Security) and Part 2 (Privacy) 109
NOTE: TR 103 534-1 is the present document 110
TR 103 535 Guidelines for semantic interoperability in industry 111
TR 103 536 Strategic / technical approach on how to achieve interoperability/interworking of existing standardized 112 IoT Platforms 113
TR 103 537 Plugtests™ preparation on Semantic Interoperability 114
TR 103 591 Privacy study report; Standards Landscape and best practices 115
1.2 Scope of the present document 116
The present document presents teaching material to allow readers, identified by role, to gain knowledge of the 117
fundamentals of IoT security. 118
The document is structured as a set of annexes each containing the outline of training material. 119
NOTE: In some cases the complete training material is provided in linked applications or modules, particularly 120 where animated, audio or video content forms a part of the material. 121
The annexes contain training material in the following areas: 122
Threat, Vulnerability and Risk Analysis (TVRA) in IoT 123
- The role of TVRA is primarily to ensure that a system is designed and deployed with a thorough 124
understanding of the environment in which it will be deployed, the purpose of the system, the 125
components or assets of the system, the links between the deployment and its environment, and the 126 technical/procedural/regulatory basis of the system. Having this core understanding alongside an analysis 127
of the threats and threat agents that will seek to attack the system leads to an understanding of the risks to 128
the system. 129
- The material in this section extends from material prepared for the ETSI TVRA Workshop (March 2009) 130
and is based on the TVRA method published in ETSI TS 102 165-1 [i.2] with specific IoT use cases to 131
drive the TVRA exercise. 132
Secure configuration of IoT devices 133
- The vast majority of security failures occur as a result of poor configuration. For example reliance on 134
default security attributes (the default password conundrum). The purpose of this module is to give 135
guidance on how to securely configure IoT devices to minimise their attack surface. 136
Cryptographic security basics as they apply in IoT 137
ETSI
ETSI TR 103 534-1 V0.0.6 (2019-03)7
- Cryptography is the mathematical toolset that underpins the majority of countermeasures (i.e. 138
authentication, encryption, integrity proof and verification). The purpose of this module is to give a 139
simple grounding in the role and purpose, and the underlying mechanisms of cryptography. Amongst the 140
topics to be covered are the following: 141
Role of cryptography in security 142
Historic roots of cryptography 143
Relationship identification to pre-select cryptographic architecture 144
Core cryptographic modes 145
Secure operation of IoT devices 146
- Closely related to secure configuration is secure operation and this module addresses the measures 147
required to assure that a securely configured device can be operated securely. 148
Applying best practices to IoT security 149
- The purpose of this module is to give specific training in how to apply the best practices identified in TR 150
103 533 [i.1] to real IoT systems. 151
Programming guide for secure IoT 152
- The purpose of this module is to give guidance on secure or safe programming. By means of coding 153
examples (in programming languages including Swift, C, C++, Java) the steps to minimise security flaws 154
in programming of IoT devices. This addresses such topics as the use of … 155
Guide to selecting a training provider 156
- A guide to the identification and selection of training providers and training programmes in IoT. 157
158
159
160
161
2 References 162
2.1 Normative references 163
Normative references are not applicable in the present document. 164
2.2 Informative references 165
References are either specific (identified by date of publication and/or edition number or version number) or 166
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the 167 referenced document (including any amendments) applies. 168
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 169
their long term validity. 170
The following referenced documents are not necessary for the application of the present document but they assist the 171
user with regard to a particular subject area. 172
[i.1] ETSI TR 103 533: "SmartM2M; Security; Standards Landscape and best practices" 173
[i.2] ETSI TS 102 165-1: "CYBER; TVRA method" 174
[i.2] ETSI TR 103 534-1: "Teaching Material: Part 1 (Security)" 175
ETSI
ETSI TR 103 534-1 V0.0.6 (2019-03)8
[] ETSI TR 103 534-2: "Teaching Material: Part 2 (Privacy)" 176
[i.3] ETSI TR 103 535: "Guidelines for semantic interoperability in the industry", 2019 177
[i.4] ETSI TR 103 536: "Strategic / technical approach on how to achieve interoperability/interworking of 178
existing standardized IoT Platforms" 179
[i.5] ETSI TR 103 537: "Plugtests™ preparation on Semantic Interoperability" 180
[i.6] ETSI TR 103 591: “Privacy study report; Standards Landscape and best practices" 181
[i.8] AIOTI: "High Level Architecture (HLA), Release 4.0, June 2018" 182
[i.9] ENISA: "IoT Security Standards Gap Analysis", ISBN: 978-92-9204-275-2, DOI: 10.2824/713380 183
184
3 Definitions, symbols and abbreviations 185
3.1 Definitions 186
For the purposes of the present document, the [following] terms and definitions [given in ... and the following] apply: 187
188
3.2 Symbols 189
For the purposes of the present document, the [following] symbols [given in ... and the following] apply: 190
191
3.3 Abbreviations 192
For the purposes of the present document, the following abbreviations apply: 193
CASP CompTIA Advanced Security Practitioner 194
CIA Confidentiality, Integrity, Availability 195
CISSP Certified Information Systems Security Professional 196
DDoS Distributed Denial of Service 197
DevOps Development IT Operations 198
DevSecOps Secure DevOps 199
DNS Domain Name System 200 DoS Denial of Service 201
e-CF European e-Competence Framework 202
ENISA European Union Agency for Network and Information Security 203
ERP Enterprise Resource Planning 204
ETSI European Telecommunication Standards Institute 205
GDPR General Data Protection Regulation 206
IaC Infrastructure as Code 207
ICT Information and Communications Technology 208
IoT Internet of Things 209
ISC2 International Information System Security Certification Consortium 210
IT Information Technology 211
TOE Target of Evaluation 212 TR Technical Report 213
TVRA Threat, Vulnerability and Risk Analysis 214
215
ETSI
ETSI TR 103 534-1 V0.0.6 (2019-03)9
4 What is Security? 216
4.1 Introduction and overview 217
The question "What is Security?" is very difficult to answer succinctly. In the context of ICT, security is often taken to 218
refer to the prevention of various forms of attack on the system, or elements of the system. The purpose of this 219
document, as indicated in the Scope statement, is to provide material to allow readers, identified by role, to gain 220
knowledge of the fundamentals of IoT security. 221
Whilst these concepts are expanded upon in the remainder of the present document the complexity of "security" as a 222
topic to understand is highlighted by the many roles and process that "security" has to tackle: 223
System protection role 224
- Core CIA roles - least knowledge model to assure system operation 225
- Analytic role - data required to forecast, resolve, recover 226
Anti-adversary role 227
- Identify who gains from system breaches 228
Risk management role 229
Regulatory compliance role 230
- Assurance of technical provisions for GDPR, for Cyber-Security directive, for law enforcement … 231
A reasonable level of understanding of each of these roles, and the technologies and processes that enable them, is the 232
ultimate goal of the present document. 233
4.2 Teaching goals 234
The bulk of the material in the present document is aimed at tutor led teaching and there is a presumption of prior 235
knowledge to apply the material to the actual audience. Thus there are hints given at points in the material for the 236
tutor/teacher to drive classroom exercises. Such exercises are not definitive in that there is no 237
4.3 Learning goals 238
As for teaching goals the present document has some specific learning goals when acting as the basis of self-taught 239
material. Specific learning goals are indicated at the start of each section in order to guide the reader as to the new 240
knowledge that will be gained after completion of the material in each section. 241
242
5 Security in the context of IoT 243
5.1 A global approach to IoT Systems 244
5.1.1 Major characteristics of IoT systems 245
IoT systems are often seen as an extension to existing systems needed because of the (potentially massive) addition of 246
networked devices. However, this approach does not take stock of a set of essential characteristics of IoT systems that 247
push for an alternative approach where the IoT system is at the centre of attention of those who want to make them 248
happen. This advocates for an "IoT-centric" view. 249
Most of the above-mentioned essential characteristics may be found in other ICT-based systems. However, the main 250
difference with IoT systems is that they all have to be dealt with simultaneously. The most essential ones are: 251
Stakeholders. There is a large variety of potential stakeholders with a wide range of roles that shape the way 252 each of them can be considered in the IoT system. Moreover, none of them can be ignored. 253
ETSI
ETSI TR 103 534-1 V0.0.6 (2019-03)10
Privacy. In the case of IoT systems that deal with critical data in critical applications (e.g., e-Health, Intelligent 254
Transport, Food, Industrial systems), privacy becomes a make or break property. 255
Interoperability. There are very strong interoperability requirements because of the need to provide seamless 256
interoperability across many different systems, sub-systems, devices, etc 257
Security. As an essential enabling property for Trust, security is a key feature of all IoT systems and needs to 258
be dealt with in a global manner. One key challenge is that it is involving a variety of users in a variety of use 259
cases. 260
Technologies. By nature, all IoT systems have to integrate potentially very diverse technologies, very often for 261
the same purpose (with a risk of overlap). The balance between proprietary and standardised solutions has to 262
be carefully managed, with a lot of potential implications on the choice of the supporting platforms. 263
Deployment. A key aspect of IoT systems is that they emerge at the very same time where Cloud Computing 264 and Edge Computing have become mainstream technologies. All IoT systems have to deal with the need to 265
support both Cloud-based and Edge-based deployments with the associated challenges of management of data, 266
etc. 267
Legacy. Many IoT systems have to deal with legacy (e.g., existing connectivity, back-end ERP systems). The 268
challenge is to deal with these requirements without compromising the “IoT centric” approach. 269
5.1.2 The need for an "IoT-centric" view 270
5.1.2.1 Introduction 271
In support of an "IoT-centric" approach, some elements have been used in the present report in order to: 272
Support the analysis of the requirements, use cases and technology choices (in particular related to 273
interoperability); 274
Ensure that the target audience can benefit from recommendations adapted to their needs. 275
5.1.2.2 Roles 276
A drawback of many current approaches to system development is a focus on the technical solutions, which may lead to 277
suboptimal or even ineffective systems. In the case of IoT systems, a very large variety of potential stakeholders are 278 involved, each coming with specific – and potentially conflicting – requirements and expectations. Their elicitation 279
requires that the precise definition of roles that can be related to in the analysis of the requirements, of the use cases, etc. 280
Examples of such roles to be characterised and analysed are: System Designer, System Developer, System Deployer, 281
End-user, Device Manufacturer. Some of these roles are specifically addressed in the current report. 282
5.1.2.3 Reference Architecture(s) 283
In order to better achieve interoperability, many elements (e.g., vocabularies, definitions, models) have to be defined, 284
agreed and shared by the IoT stakeholders. This can ensure a common understanding across them of the concepts used 285
for the IoT system definition. They also are a preamble to standardisation. Moreover, the need to be able to deal with a 286
great variety of IoT systems architectures, it is also necessary to adopt Reference Architectures, in particular Functional 287
Architectures. The AIOTI High-Level Architecture (see [i.34]) is the reference for the present document. 288
5.1.2.4 Guidelines 289
The very large span of requirements, Use Cases and roles within an IoT system make it difficult to provide prototypical 290
solutions applicable to all of the various issues addressed. The approach taken in the present report is to outline some 291
solutions but also to provide guidelines on how they can be used depending on the target audience. Such guidelines are 292
associated to the relevant roles and provide support for the decision-making. 293
294
ETSI
ETSI TR 103 534-1 V0.0.6 (2019-03)11
6 Overview of IoT security challenge 295
6.1 The challenge 296
297
6.2 Conventions and terminology 298
Security documents, and the engineers and designers, often use a distinctive terminology. The primary stakeholders are 299
given names: Alice, Bob and Eve. Alice and Bob are the parties to a secure transaction, so in general terms Alice is 300 trying to establish a relationship with Bob. Eve is the generalised adversary, whose purpose is to attack the relationship 301
between Alice and Bob. 302
One of the common models is to consider security in broad terms as determination of the triplet {threat, security-303
dimension, countermeasure} such that a triple such as {interception, confidentiality, encryption} is formed. The threat 304
in this case being interception which risks the confidentiality of communication, and to which the recommended 305
countermeasure is encryption. More detail discussion of the security dimensions is given below. However, the nature of 306 threats needs greater examination. Threats can be gathered into several families: 307
Masquerade: In this case Eve attempts to impersonate Bob such that Alice will interact with Eve in the belief 308
that she is talking to Bob. Masquerade attacks are most often countered by the use of authentication schemes. 309
Manipulation: In this case Eve attempts to modify data that Alice is trying to access (generally given to Alice 310
by Bob). Examples include falsifying location, falsifying an account balance, introducing malicious code to an 311
application. Countering manipulation is often difficult but includes the use of cryptographic checksums, error 312
detection and correction codes, digital signatures. The security problem is to ensure that identification and 313
proof of manipulation cannot be manipulated too. 314
Interception: In this case Bob is sending something to Alice and Eve views it in transit. Conventionally 315
interception threats are countered by encryption (in which case Eve can see that communication exists between 316
Alice and Bob but is unable to see the content of that communication). 317
Theft: The theft attack extends the interception attack in that whilst Eve not only observes the communication 318
between Alice and Bob she may also intercept and redirect such that Alice never receives the data, or copies 319
the data such that whilst Alice receives the data Eve also has the data. The means to counter theft include 320
various forms of access control, encryption (if data is stolen it cannot be read), manipulation control including 321
things such as proof of source (if stolen data is re-presented this uses techniques that can reveal it does not 322
actually belong to the presenting party). 323
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 324
attack is just that, Eve directly attacks Alice or Bob or the link between them. However, Eve can also attack Alice, Bob 325
or their relation by attacking something else altogether, these are termed side-channel attacks. For example in the 326
internet there are several tools and protocols used to ensure that Alice and Bob can connect, so Eve can attack one of 327
those tools or protocols and prevent Bob from ever being able to attach to Alice, this could be achieved by poisoning 328
the DNS system, or attacking the network in such a way that valid traffic never reaches Alice (a Denial of Service 329
(DoS) attack, or a Distributed Denial of Service (DDoS) attack). 330
In addition to attacks against device function there are a class of attacks that use devices owned by Alice to act as 331
adversaries on behalf of Eve. Commonly these are referred to as “Trojan” devices, in reference to the myth of the gift of 332
the wooden horse from the Greeks to the people of Troy containing a hidden cadre of Greek soldiers who when inside 333
the city launched an attack (in other words an apparently benign package contains a hidden payload used to attack the 334
host). 335
6.3 Trust and roots of trust 336
Security mechanisms and procedures are predicated on some form of trust. There is equivalence in the real world of 337 course: Alice trusts the bank to store her money and to make it available on demand; Alice trusts that the bank will not 338
lose her money. The reasons that Alice trusts her bank are not always explicit but are a combination of peer review and 339
peer experience, of knowledge that banks are overseen by a regulatory authority, of independent reviews. 340
ETSI
ETSI TR 103 534-1 V0.0.6 (2019-03)12
In the security domain the concept of trust is complex and multi-tiered. For an analogy to examine the levels of 341
complexity we consider that Alice is travelling across town to make a deposit of cash (very large amount) in her bank. 342
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-343
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 344
cash, e.g. the denomination of each note and the number of each note, and she will keep this record separate from the 345
cash itself. Alice has to trust that the cash she is carrying is legitimate so she trusts that she has received them from a 346
reputable source. If Alice has a small window of time to take the cash to the bank she has to trust her transport. In 347
choosing transport she has to make a number of decisions regarding speed of transfer, safety of transfer, cost of transfer, 348
and exposure during transfer to Eve. Alice may choose public transport, or private transport, she may choose to walk, to 349
cycle, to drive. Each of these offers a different level of risk and places the cash she is transferring at a different level of 350
risk too. In determining which transport option to select Alice has to determine which she trusts most to get her to the 351 bank in time with lowest risk to the cash she is carrying. It would be easy to continuously extend the scenario and in a 352
teaching context the teacher would be recommended to perform a brainstorming exercise with the class to tease out the 353
trust relationships that Alice has to maintain in the overall process of taking cash from home to safely depositing it in 354
the care of the bank. 355
Teaching exercise: To allow students to build a map of the trust relationships for the scenario. 356
6.4 The CIA paradigm 357
Notwithstanding the discussion across TR 103 533 [] the purpose of security technologies is multi-fold: 358
Confidentiality: Information shared by Alice with Bob is only visible to Bob and Alice. If Eve can access the 359 information she cannot ascertain the meaning of the content. Primarily achieved using encryption. 360
Integrity: Information shared by Alice with Bob can be proven by Alice not to have been manipulated by a 3rd 361
party (Eve). Bob can verify this is the case. Primarily achieved using hash functions with have specific 362
characteristics. 363
Availability: This addresses the aim of ensuring that an authorized party (i.e. Alice) is able to access services 364
or information when needed. In other words, that Alice has access only to those assets she is allowed to access 365
and that they are available to Alice when legitimately demanded, and that an adversary, Eve, does not have 366
access. The technologies that address this include Identity Management, Authentication and Access Control, in 367
addition considerations in the availability domain include reliability and resilience which, whilst not strictly 368
addressed by security technology, impact on availability. 369
One of the many characteristics of IoT is that the number of communicating entities is very large and the number of 370
possible relationships per device is larger than, say, cellular telecommunication. 371
As a trivial example we can imagine that IoT communications security is equivalent to sending presents to somebody. 372
To ensure the recipient does not know the content before unwrapping, the sender masks the content by wrapping the gift 373
– this makes the content confidential. The intended recipient is clearly indicated on the label as is the sender – this 374
identifies the parties to the transaction and depending on how names are written may confer some proof of identity. 375
Finally, in order to ensure the package is not damaged the sender adds packaging that protects it – this is some means of 376
ensuring the integrity of the package is maintained in transit. Translating this to IoT data from A to B the data can be 377
encrypted to confer confidentiality, the parties A and B have to be able to prove their identity to confer authenticity to 378
the exchange, and the parties can add data to the package that will be used to assure and verify the integrity of the 379
package. 380
There are a number of complexities in IoT that arise from the nature and number of both devices and connections. The 381
most obvious of these is key management. 382
383
6.5 Review of landscape and best practices 384
A summary before consideration of using any security guidance or best practice is to reflect on the purpose of security 385
technologies and processes. 386
System protection role 387
- Core CIA roles - least knowledge model to assure system operation 388
ETSI
ETSI TR 103 534-1 V0.0.6 (2019-03)13
- Analytic role - data required to forecast, resolve, recover 389
Anti-adversary role 390
- Identify who gains from system breaches 391
Risk management role 392
Regulatory compliance role 393
- Assurance of technical provisions for GDPR, for Cyber-Security directive, for law enforcement … 394
In looking at best practice addressed to non-security professionals, e.g. to developers to ensure that they have designed 395
the necessary capability (the power or ability to do something) and functionality (the quality of being suited to serve a 396
purpose well) into their products and services, to managers to ensure they have recruited the necessary expertise, to 397
users to ensure they maximise the available features of their devices, the guidance and best practices have to address 398
some or all of the roles in the foregoing list. Guidelines and best practices should be written in such a way that they 399 recognise the overlap of each of the roles. For example in looking at guidance that limits the attack surface exposed to 400
an adversary (anti-adversary role) it is necessary to consider guidance on how to achieve proof of who is acting in the 401
system (system protection and CIA roles) but as this may have an impact on regulatory compliance the guidance in that 402
role needs to be considered, also if data is required to protect the system by analysis of how the system is used then the 403
guidelines for system protection by analytics needs to be taken into account. 404
6.6 Rationale for training and education in IoT security 405
The ENISA gap analysis […] identified a significant gap in the understanding of security and its application to systems. 406
The present report and its included training material is one means of addressing that perceived gap. However a further 407 strong message, made in TR 103 533, is that whilst in many fields there is an ability to learn "on the job", for security 408
there is no such luxury. A danger that is not expressed in any of the guidelines cited in TR 103 533 is the consequence 409
of incomplete implementation, or of incomplete knowledge. Similarly even if all of the teaching material given in, and 410
cited by, the present document, is followed the resulting knowledge should never be treated as complete, and certainly 411
not sufficient to combat an equally trained adversary. 412
The world of security is often downplayed as non-adversarial. This is not the approach taken in the present document. 413 Rather it is assumed that the system is never benign and that adversaries are always at work. 414
7 Security use cases 415
In IoT, as in most systems once they have been sufficiently decomposed, the core idea is that an entity, referred to as 416
Alice, wants to exchange information with another entity, referred to as Bob, in the presence of an adversary, Eve. In 417
the world of IoT certain assumptions can be made regarding Alice and Bob, and about the means by which they are 418
connected. 419
The thought experiment that will underpin all of the material in the present document is the following: 420
"How can Alice transfer something to Bob in such a way that she is assured that only Bob will receive it, that Eve is 421
unable to masquerade as Bob, that Eve cannot see what Alice is transferring, and where Eve is unable to manipulate 422
what Alice is transferring?" 423
The architecture and mechanics of security are to some extent determined by the set of known variables in the thought 424
experiment. This is captured, somewhat clumsily but accurately in the statement attribute to Donald Rumsfeld as "There 425 are known knowns. These are things we know that we know. There are known unknowns. That is to say, there are things 426
that we know we don't know. But there are also unknown unknowns. There are things we don't know we don't know." In 427
designing and understanding security the knowledge of the security designer has to be such that the known knowns are 428
maximised, and the set of unknown knowns is minimised. This means knowing as much as possible about each of Alice 429
and Bob and how they connect, and of how Eve could subvert the system. In recognising that there are known 430
unknowns the designer has to be able to minimise any impact they would have, and this is essentially to assume that 431
Eve will try new ways to attack the system thus whilst it is not necessary to know exactly how Eve will operate the 432
system can be designed to limit the degree of freedom Eve has. 433
An everyday example of the thought experiment is the sending of a gift. Alice wishes to send Bob a gift. In order to 434
make sure it gets to Bob she addresses the package such that there is no ambiguity in who it is being sent to. She may 435
ask for proof of delivery. She may ask for a trusted carrier to carry the package. In order to prevent Eve seeing what is 436
ETSI
ETSI TR 103 534-1 V0.0.6 (2019-03)14
in the gift Alice will wrap it, and to ensure it isn't broken in transit Alice will also provide protective wrapping (bubble 437
wrap perhaps). Each of these actions is a security action: Making sure Bob is the recipient is the act of Identification 438
and Authentication; Concealing the gift is providing confidentiality to the gift; Bubble wrap acts to preserve the 439
integrity of the package. This is the everyday application of the CIA paradigm that underpins almost all security work. 440
441
ETSI
ETSI TR 103 534-1 V0.0.6 (2019-03)15
Annex A: 442
Threat, Vulnerability and Risk Analysis in IoT 443
A.1 Role of TVRA 444
The purpose of the TVRA exercise is to identify where risks exists, to classify the level of the risk, and to guide the 445
application of countermeasures that manage risk to an acceptable residual value. 446
The TVRA method, or process, consists of the following steps: 447
1) Identification of the Target of Evaluation (TOE) resulting in a high level description of the main assets of the 448
TOE and the TOE environment and a specification of the goal, purpose and scope of the TVRA. 449
2) Identification of the objectives resulting in a high level statement of the security aims and issues to be 450
resolved. 451
3) Identification of the functional security requirements, derived from the objectives from step 2. 452
4) Inventory of the assets as refinements of the high level asset descriptions from step 1 and additional assets as a 453
result of steps 2 and 3. 454
5) Identification and classification of the vulnerabilities in the system, the threats that can exploit them, and the 455 unwanted incidents that may result. 456
6) Quantifying the occurrence likelihood and impact of the threats. 457
7) Establishment of the risks. 458
8) Identification of countermeasures framework (conceptual) resulting in a list of alternative security services and 459
capabilities needed to reduce the risk. 460
9) Countermeasure cost-benefit analysis (including security requirements cost-benefit analysis depending on the 461
scope and purpose of the TVRA) to identify the best fit security services and capabilities amongst alternatives 462
from step 8. 463
10) Specification of detailed requirements for the security services and capabilities from step 9. 464
Many of the terms used in the TVRA are specialised thus need greater examination which is provided throughout this 465
annex. 466
467
468
A.2 Identification of IoT Security environment 469
In general terms an IoT device requires connectivity to services or components across a network. This IoT pre-requisite 470
implies the existence of at least one open interface that can be used to attack the IoT device. It is also implied that the 471
network expects connections from IoT devices which again implies an open interface that can be used to attack the IoT 472
dependent infrastructure. 473
The identification of the IoT security environment establishes the Target of Evaluation (TOE), that is the area in which 474
each of Alice, Bob and Eve are considered to operate. The result is a high level description of the main assets of the 475
TOE and the TOE environment and a specification of the goal, purpose and scope of the TVRA which by implication is 476
the IoT security environment. 477
This addresses steps 1,2,3 and 4 of the method/process. 478
ETSI
ETSI TR 103 534-1 V0.0.6 (2019-03)16
A.3 Modelling of threats and vulnerabilities 479
This addresses steps 5 and 6 of the method/process. 480
A.4 Determination of risk 481
This addresses step 7 of the method/process. 482
A.5 Monitoring of threat level 483
… 484
A.6 Determination of applicable countermeasures 485
This addresses steps 8, 9 and 10 of the method/process. 486
487
A.7 Revision, verification and validation 488
Redoing all the steps with the new assets. 489
490
491
ETSI
ETSI TR 103 534-1 V0.0.6 (2019-03)17
Annex B: 492
Applying best practices to IoT security 493
The consumer IoT document from TC CYBER provides basic guidance for organizations involved in the development 494
and manufacturing of consumer IoT devices [i.xx] 495
Not having universal default passwords 496
Implementing means to manage reports vulnerabilities 497
o Companies that provide internet-connected devices and services shall provide a public point of 498
contact as part of a vulnerability disclosure policy in order that security researchers and others are 499
able to report issues. 500
o Disclosed vulnerabilities should be acted on in a timely manner. 501
o Companies should continually monitor for, identify and rectify security vulnerabilities within 502
products and services they sell, produce, have produced and services they operate as part of the 503
product security lifecycle. 504
Keep software updated 505
o All software components in consumer IoT devices should be securely updateable. 506
o The consumer should be informed by the appropriate entity, such as the manufacturer or service 507
provider, that an update is required. 508
o When software components are updateable, 509
updates shall be timely. 510
an end-of-life policy shall be published for devices that explicitly states the minimum length 511
of time for which a device will receive software updates and the reasons for the length of 512
the support period. This policy shall be published in an accessible way that is clear and 513
transparent to the consumer. 514
the need for each update should be made clear to consumers and an update should be easy 515
to implement. 516
updates should, where possible, maintain the basic functioning of the device, which can be 517
critical to remain available during an update. 518
provenance of software updates should be assured and security patches should be 519
delivered over a secure channel. 520
o For constrained devices that cannot have their software updated, 521
the product should be isolable and the hardware replaceable. 522
the rationale for the absence of software updates, the period of hardware replacement 523
support and an end-of-life policy should be published in an accessible way that is clear and 524
transparent to the consumer. 525
Securely store credentials and security-sensitive data 526
Communicate securely 527
o Security-sensitive data, including any remote management and control, should be encrypted in 528
transit, with such encryption appropriate to the properties of the technology and usage. 529
o All keys should be managed securely. 530
Minimize exposed attack surfaces 531
o Unused software and network ports should be closed. 532
o Hardware should not unnecessarily expose access to attack (e.g. open serial access, ports or test 533
points). 534
o Software services should not be available if they are not used. 535
o Code should be minimized to the functionality necessary for the service/device to operate. 536
o Software should run with least necessary privileges, taking account of both security and functionality 537
Ensure software integrity 538
o Software on IoT devices should be verified using secure boot mechanisms, which require a hardware 539
root of trust. 540
o If an unauthorized change is detected to the software, the device should alert the consumer and/or 541
administrator to an issue and should not connect to wider networks than those necessary to 542
perform the alerting function. 543
Ensure that personal data is protected 544
ETSI
ETSI TR 103 534-1 V0.0.6 (2019-03)18
o Device manufacturers and service providers shall provide consumers with clear and transparent 545
information about how their personal data is being used, by whom, and for what purposes, for each 546
device and service. This also applies to third parties that can be involved, including advertisers. 547
o Where personal data is processed on the basis of consumers' consent, this consent shall be obtained 548
in a valid way. 549
o Consumers who gave consent for the processing of their personal data shall be given the 550
opportunity to it at any time. 551
Make systems resilient to outages 552
o Resilience should be built in to IoT devices and services where required by their usage or by other 553
relying systems, taking into account the possibility of outages of data networks and power. 554
o As far as reasonably possible, IoT services should remain operating and locally functional in the case 555
of a loss of network and should recover cleanly in the case of restoration of a loss of power. 556
o Devices should be able to return to a network in an expected, operational and stable state and in an 557
orderly fashion, rather than in a massive-scale reconnect. 558
Examine system telemetry data 559
o If telemetry data is collected from IoT devices and services, such as usage and measurement data, it 560
should be examined for security anomalies. 561
o If telemetry data is collected from IoT devices and services, the processing of personal data should 562
be kept to a minimum and such data should be anonymized. 563
o If telemetry data is collected from IoT devices and services, consumers shall be provided with 564
information on what telemetry data is collected and the reasons for this. 565
Make it easy for consumers to delete personal data 566
o Devices and services should be configured such that personal data can easily be removed from them 567
when there is a transfer of ownership, when the consumer wishes to delete it, when the consumer 568
wishes to remove a service from the device and/or when the consumer wishes to dispose of the 569
device. 570
o Consumers should be given clear instructions on how to delete their personal data. 571
o Consumers should be provided with clear confirmation that personal data has been deleted from 572
services, devices and applications. 573
Make installation and maintenance of devices easy 574
o Installation and maintenance of IoT devices should employ minimal steps and should follow security 575
best practice on usability. Consumers should also be provided with guidance on how to securely set 576
up their device 577
Validate input data 578
o Data input via user interfaces and transferred via application programming interfaces (APIs) or 579
between networks in services and devices shall be validated. 580
581
ETSI
ETSI TR 103 534-1 V0.0.6 (2019-03)19
Annex C: 582
Cryptographic security basics 583
C.1 Role of cryptography in security 584
585
C.2 Historic roots of cryptography 586
Roots of substitution, transposition, keying and of one way backdoor functions. 587
C.3 Relationship identification to pre-select cryptographic 588
architecture 589
Using roots of cardinality of relationships to be secured in order to identify the crypto mode. 590
C.4 Core cryptographic modes 591
592
593
594
595
596
ETSI
ETSI TR 103 534-1 V0.0.6 (2019-03)20
Annex D: 597
Secure configuration of IoT devices 598
The following have been recommended when it comes to configuring IoT devices according the GSMA guideline [i.xx] 599
(GSMA IoT security Assessment Checklist). This is by no means complete, this report has considered the critical and 600
High recommendation list. For Medium and Low recommendation please refer to the GSMA guide line. 601
Critical Recommendation: critical recommendations define a secure endpoint architecture. Without these 602
recommendations, the endpoint will have an incomplete security profile that will be abused by an adversary. 603
Endpoint: A generic term for a lightweight endpoint, Complex Endpoint, gateway or other connected device (IoT 604
devices falls under this definition). 605
Recommendation
Implement a Service Trusted Computing Base Create options to choose a set of physical server models.
Choose a set of Cloud platforms or Virtual Machine (VM) images.
Define a set of applications, libraries and configuration files to be run on our
computing platform.
Define a container environment.
Generate an application image.
Provide capabilities that will verify that procedure is documented, in place and
implemented.
Cryptographically signed an archive of our application image using the Tier TCB
signing key.
Application image is signed using standardised cryptographic algorithms and this is
documented.
Verify that our procedure is documented, in place and implemented.
Securely stored the archive of our application image and the signature.
Ensure there is no linkage between the storage of the application image and the
signature.
5.2 Define an Organizational Root of Trust
Ensure each computing platform in our service is cryptographically authenticated
when communicating with other computing platforms.
Have a Hardware Security Module (HSM) to store our organizational root secret.
Generate a root secret and/or certificate.
Ensure the secret is stored securely and protected throughout its lifecycle.
Generate a set of one or more signing keys to be used for Tier TCB signing key.
Ensure the organisation has signed the public facet of the signing key with the
organizational root.
Ensured the signing keys cannot be used without authentication and authorization
from the business and engineering leads.
Define a Bootstrap Method Utilise an API that allows the application to cryptographically identify itself to its
peers.
Define how our application will authenticate Endpoints, Service Peers, and Partners.
Define each application’s configuration.
ETSI
ETSI TR 103 534-1 V0.0.6 (2019-03)21
Ensured each application has a unique identity.
Define a Security Infrastructure for Systems
Exposed to the Public Internet
Implement a DDoS-resistant infrastructure.
Implement a Load-Balancing infrastructure.
Implemented redundancy systems.
Implemented Web Application Firewalls.
Front-end security has been applied to all protocols implemented by the services.
Both ingress and egress filtering are managed.
Define a Persistent Storage Model Each server has access to persistent storage.
Each server or service accessing a shared storage system uses unique credentials
identifying a unique Endpoint, Partner or User.
Define an Administration Model Define how our administrators will authenticate with each system.
Use multifactor authentication to authenticate administrators to each system.
Define how systems snapshots can be taken.
Define how changes can be made and how these changes are tracked.
Define a Systems Logging and Monitoring
Approach
Implement monitoring and logging at the communications network infrastructure
level to monitor and log the following:
Increased data traffic;
Increased data traffic in an odd direction.
Implement monitoring and logging at the application tier level to monitor and log the
following:
Increased data traffic;
Increased data traffic in an odd direction;
Egress data traffic from a resource that; shouldn’t need egress;
Abnormal changes in system time on a particular host.
Implement monitoring and logging at the system-level to monitor and log the
following:
Abnormal CPU utilization;
GPU utilization for systems with no visual; interface, but have a GPU as a part of
the CPU;
Disk or network-storage utilization;
Abnormal changes in system time on a particular host.
Define an Incident Response Model In the event of an attack our organization has the capability to diagnose the source
of a compromise, patch the system and deploy the patch on all existing
infrastructure.
Define a Recovery Model Have procedure in place for the recovery of information and capability within our
application tier.
Have a model in place for validating that the application or system has been
sufficiently patched prior to recovery.
Define a Sunsetting Model Have a process in place that guarantee that all the technologies for our service are
revoked and decommissioned in such a way that an adversary cannot take on the
identity of, or use the facilities of, the given technology.
Define a Set of Security Classifications Create defined security classifications for internal organizational policies for service
data security.
ETSI
ETSI TR 103 534-1 V0.0.6 (2019-03)22
606
The following are high priority Recommendations: The following are high priority Recommendations: High priority 607
recommendations represent the set of recommendations that should be implemented, but only if the endpoint 608
architecture requires it. For example, not all endpoint architectures require a tamper resistant product casing. These 609
recommendations should be evaluated to determine if the business case deems them a requirement. 610
Note: This recommendation intended for IoT
Service Providers only.
Have defined security classifications for our partner organizational policies for
service data security.
Implement technical policy within our service based upon our defined security
classifications.
Define Classifications for Sets of Data Types Have clearly defined types of information that are acquired, generated, and
disseminated to peers in the IoT system, and how our organization will treat these
types of data.
Recommendation
Define a Clear Authorization Model Have an authorization model in place that defines how our business will act on behalf
of our users.
Have an authorization model that defines how our Partners will act on behalf of our
users.
Have embedded granular control of the authorization model to allow users to
configure when Partners have access to certain capabilities, and how often.
Manage the Cryptographic Architecture All technologies deployed within the service use standardised cryptographic
algorithms with appropriate key lengths as recommended by an oversight
organization.
The cryptography used within our service is actively managed, and adjusted to meet
changing specifications over time.
Passwords, keys and pins used by a user or endpoint are never stored or passed over
the network in plaintext, even if the communications channel is secured through
encryption.
Define a Communications Model Each system in the service implements mutual authentication with the other systems
within the service.
Each system in the service ensures data confidentiality.
Each system in the service ensures data integrity.
A root of trust is used to ensure that each entity in our communications model is
authorized by the same organization as its peer.
Provisioning and revocation are part of our communications model, and guarantee
that any compromised secret or identity can be removed from the system with
minimal effort.
Use Network Authentication Services Evaluate whether the authentication technology provided by our network partner will
add value at the application layer within our service.
Use network authentication services within our service.
Provision Servers Where Possible Server provisioning process ensures that our servers are security hardened and ready
for deployment in their production environments.
Define an Update Model Have a secure defined process to update the execution environment within our
servers.
Have a secure defined process to update the application image within our servers.
Have a secure defined process to update the TCB within our servers.
Have a patch management process to maintain the 3rd party services and
technologies used within our service infrastructure.
ETSI
ETSI TR 103 534-1 V0.0.6 (2019-03)23
611
612
613
614
Define a Breach Policy for Exposed Data Have processes in place to evaluate and detect whether our Partners are involved in
business practices that breach the technological controls or policies set in place to
guard our user’s data and privacy.
Force Authentication Through the Service
Ecosystem
Always authenticates users using a centrally available service.
Authentication service enforces policies and procedures that mandate how
authentication tokens can be used, and for what period of time.
Metrics are gathered by our authentication service to determine if the user has
migrated to an alternative computing platform, but is using the same token.
Depending on the type and speed of movement of authentication requests, our
authentication service may invalidate tokens.
Implement Input Validation All data acquired by our service from an endpoint, user, or purported user is analysed
for anomalies.
Implement Output Filtering All data presented by our service to an endpoint, user, or purported user is analysed
for anomalies.
Enforce Strong Password Policy Password policies protect against stealing our password database.
Password policies protect against cracking individual passwords.
Password policies protect against brute-force attacks.
Password policies protect against malware-based attacks.
Password policies protect against using hard-coded or default passwords.
Passwords are not hard-coded in our system.
Users always have the ability to change their password at any time.
Define Application Layer Authentication and
Authorization
The actions and identities of our user, administration and partner authorization
technologies are configured and authenticated using a separate system.
Have separate storage systems for Endpoint identities, Users, Administrators and
Partners organisations.
Default-Open or Fail-Open Firewall Rules and
System Hardening
Use firewall and network traffic rulesets and these rules are set in our infrastructure
before the service is deployed.
Employs operating system hardening to ensure that the effects of failed
infrastructure do not result in a catastrophic security event.
Evaluate the Communications Privacy Model Communication Privacy Model ensures the cryptographic uniqueness of each
message.
Communications Privacy Model ensures our service does not create Transmission
patterns that can impact user privacy.
Communications Privacy Model ensures our service does not use Plaintext metadata.
Communications Privacy Model ensures our service does not use Hardware addresses
or attributable serial numbers.
ETSI
ETSI TR 103 534-1 V0.0.6 (2019-03)24
Annex E: 615
Secure operation of IoT devices 616
The following have been recommended when it comes to configuring IoT devices according the GSMA guideline [i.xx] 617
(GSMA IoT security Assessment Checklist). This is by no means complete, this report has considered the critical and 618
High recommendation list. For Medium and Low recommendation please refer to the GSMA guide line. 619
Critical Recommendation: critical recommendations define a secure endpoint architecture. Without these 620
recommendations, the endpoint will have an incomplete security profile that will be abused by an adversary. 621
Recommendation
Implement an Endpoint Trusted Computing Base The TCB implemented within our endpoints performs image validation for all software
before its installation on the endpoint.
The TCB implemented within our endpoints performs image validation for all software
before its execution on the endpoint.
The TCB implemented within our endpoints enables and enforces mutual-
authentication of network peers.
The TCB implemented within our endpoints enables and enforces separation of duties
within the IoT security architecture.
The TCB implemented within our endpoints enables and enforces secure provisioning
and personalization.
The TCB implemented within our endpoints adequately protects secrets stored locally
within the endpoint.
The TCB implemented within our endpoints enables and enforces isolated environment
security (or connectionless site security).
The TCB implemented within our endpoints features a random number generator.
The TCB implemented within my endpoints provides protection against unauthorised
access to RAM (e.g. RAM scrambling).
Our service supports a personalised key model.
Our service utilises standards based TCB protocols and technologies. (Please state which
standards in the notes column).
Utilize a Trust Anchor Endpoints utilise a proven trust anchor to verify the integrity of their own platforms.
Endpoints utilise a proven trust anchor to authenticate their peers.
Use a Tamper Resistant Trust Anchor Trust anchor has extra physical security to guard against certain classes of physical
attack, such as FIBs, side-channel analysis and glitching.
Trust anchor is certified (e.g. by FIPS [5], EMVCo [6] or Common Criteria [7]).
Utilise an API for the TCB Implemented an API to ensure:
All signature verification is performed by the TCB;
No secret keys are exposed from the TCB;
Key exchanges can be performed by the TCB on behalf of the application;
Decryption can be performed by the TCB;
Encryption can be performed on the TCB;
Message signing can be performed on the TCB;
Secure message padding can be performed on the TCB;
Confidentiality and Integrity between the TCB and the application.
The TCB API is only accessible by privileged applications running on the Endpoint.
ETSI
ETSI TR 103 534-1 V0.0.6 (2019-03)25
Defining an Organizational Root of Trust Have defined cryptographic policies and procedures for our endpoints that govern how
identities, applications, and communications can and should be cryptographically
secured.
A root private key is used to digitally sign other keys used in the key hierarchy.
All keys and their corresponding signatures are stored in the trust anchor used by the
TCB.
Personalize Each Endpoint Device Prior to
Fulfilment
Endpoint devices are personalised with cryptographically unique identities in their
production environment.
Endpoint device identities are catalogued, along with their unique identifiers matching
the identity, in a system that cannot be tampered with.
Minimum Viable execution Platform Endpoints use a Minimal Viable execution Platform to create a reliable execution
environment.
Uniquely Provision Each Endpoint Have implemented a secure provisioning process for our endpoints that helps:
Distinguish between active and deactivated devices;
Associate Endpoints with networks or other resources linked with a particular
customer;
Customize the Endpoint according to the customer’s needs;
Determine whether a particular customer or Endpoint has been compromised.
Endpoint Password Management Enforce strong password management with our endpoints to:
Mitigate against Brute-force attack;
Disable the use of default or hardcoded passwords;
Ensure password best-practice enforcement;
Disallow display of user credentials on login interfaces;
Enforce thresholds and incremental delays for invalid password attempts.
Use a Proven Random Number Generator Endpoint device TCB is capable of truly random number generation.
TCB random number generation is approved by FIPS, EMVCo or Common Criteria.
Cryptographically Sign Application Images All endpoint applications stored outside of our endpoint’s CPU core ROM are
cryptographically signed.
All application images stored in removable media on the endpoint are cryptographically
protected (integrity and confidentiality).
Remote Endpoint Administration Do not place private cryptographic components into insecure storage on Endpoints.
Use unique administrative tokens (cryptographic keys or passwords) per each Endpoint.
Enforce the use of administrative passwords that conform to best practices regarding
password complexity and length.
Enforce two-factor authentication for administrators.
Restrict administrative access to a secured communication channel.
Embed remote administrative capabilities into publicly accessible applications or APIs.
Enforce confidentiality and integrity on the administrative communications channel.
Diminished the potential for replay of administrative commands by ensuring the
communications protocol has adequate entropy.
Logging and Diagnostics Implement endpoint anomaly detection.
Implement endpoint logging.
Implement endpoint diagnostics.
Enforce Memory Protection Enforce memory protection in our endpoints using Memory Management Units.
ETSI
ETSI TR 103 534-1 V0.0.6 (2019-03)26
622
The following are high priority Recommendations: High priority recommendations represent the set of 623
recommendations that should be implemented, but only if the endpoint architecture requires it. For example, not all 624
endpoint architectures require a tamper resistant product casing. These recommendations should be evaluated to 625
determine if the business case deems them a requirement. 626
Enforce memory protection in our endpoints using Memory Protection Units.
Secure Bootloaders
Bootloader is located securely in internal ROM.
Bootloader is not in internal ROM but our CPU securely verifies the bootloader code.
Bootloader cryptographically verifies the application image to be executed.
Bootloader does not allow application images to be loaded from arbitrary storage
locations.
All critical areas of persistent memory are locked using hardware locks.
Locking Critical Sections of Memory All critical applications stored in executable regions of persistent memory, such as first-
stage bootloaders or Trusted Computing Bases, are stored read-only.
All critical areas of persistent memory are locked using hardware locks.
Perfect Forward Secrecy Implement perfect forward secrecy.
Endpoint Communications Security Implement communications security to ensure the authentication of network peers.
Implement communications security to ensure the confidentiality of data.
Implement communications security to ensure the Integrity of messages.
Existing and well analysed, standardised, security protocols.
Authenticating an Endpoint Identity Endpoints are able to prove that they truly represent their cryptographically unique
identities using the process described in the guidelines.
Recommendation
Use Internal Memory for Secrets Endpoint processors use internal CPU memory that is not accessible to code running
outside the TCB for the processing of core secrets and cryptographic keys that are not
contained within a trust anchor.
Executable code ensures that any memory routines that process core secrets or
cryptographic keys use specific regions of memory that are guaranteed to be internal
processor memory.
Anomaly Detection Enforce anomaly detection for our Endpoints which can detect adversarial behaviour,
including:
Erratic reboots or device resets;
Leaving or joining a communications network at erratic intervals;
Connecting to abnormal service Endpoints, or connecting to service Endpoints at
inappropriate times;
A significantly different network traffic fingerprint than normal;
Multiple poorly-formed messages sent from the Endpoint to service platforms.
Use Tamper Resistant Product Casing Endpoints implement tamper resistant security controls.
Endpoints contain circuits that invalidate NVRAM when a casing is opened.
Endpoints contain Sensors that blow security fuses when abnormal conditions (e.g.
light, temperature or voltage range) are detected.
Endpoints contain Sensors that trigger an alert when a physically static device’s location
is moved.
Endpoints uses Epoxy covering for core circuit components.
ETSI
ETSI TR 103 534-1 V0.0.6 (2019-03)27
627
628
Endpoints raise Alerts when either internal or removable components are removed
from the device.
Enforce Confidentiality and Integrity to/from the
Trust Anchor
All communications to and from the endpoint’s trust anchor are authenticated and
enforce confidentiality and integrity.
Over the Air Application Updates Endpoints support secure over the air application updates.
In the event of an application update failure our endpoint either reverts to a backup
image or it notifies the IoT Service Ecosystem that a fault has occurred.
Improperly Engineered or Unimplemented Mutual
Authentication
Each peer in our IoT service mutually authenticates with all other peers in our
ecosystem.
Each peer in our IoT service encrypts and signs the messages its sends to the other
peers in the ecosystem.
Each peer that receives messages in our ecosystem cryptographically validates the
message before acting on it.
Privacy and Unique Endpoint Identities Endpoints use random addresses when connecting to new communications networks.
Let users decide if they want their public keys exposed when connecting to new
communications networks.
Run Applications with Appropriate Privilege Levels The applications running on our endpoints do not require super-user privileges during
normal runtime.
nsure that applications only run with super-user privileges when that require initial
access to resources.
Enforce a Separation of Duties in the Application
Architecture
The applications running on our endpoints have different user identities associated with
each unique process.
Hardware level memory protection is utilised within our endpoint devices and privilege
levels are enforced according to our security architecture.
Unprivileged software is restricted from accessing privileged resources such as drivers,
configuration files and other objects.
Enforce Language Security Endpoint applications are built using a programming language that enhances the
security of the applications.
Implement Persistent Pentesting Have a persistent pentesting strategy in order to validate the security of our endpoints
software and avoid insecure configurations.
ETSI
ETSI TR 103 534-1 V0.0.6 (2019-03)28
Annex F: 629
Programming guide for secure IoT 630
F.1 Overview 631
Some programming languages are more open to allowing security errors than others. How data is passed between 632
functions is one concern, and the interpretation of data at source and destination is often a difficulty. 633
F.2 Data passing issues 634
Data can be passed essentially in one of 2 ways: By reference; By value. In the former all that is actually passed is a 635
pointer to some memory location where the data is expected to be found, in the latter the actual data is passed. 636
F.3 Memory allocation issues 637
Using more memory than is required allows unexpected data to leak into and out of a system. For example if a 638
programmer wants to store 10 characters, he can (using C) use the code: 639
char *ptr = (char *) malloc(10); 640 641 This allocates 10 bytes of storage at the memory address of ptr. 642
Now the programmer can attempt to store something at that location. 643
char name[20]; 644 memcpy (name, ptr, 20); 645 646 This tries to store a 20 byte record at a 10 byte location. 647
There are a number of ways to avoid such errors including not using malloc() but using calloc() which initialises the 648
memory location to a known value. The programmer should also ensure that the data is going to fit: 649
If len(name) < len(ptr) … 650 651 652
F.4 Data type issues 653
The storage of data using a type that is larger than necessary is often achieved on the fly in many programming 654
languages. For example it is possible to declare a set of variables as integers but to explicitly cast one of them to be a 655 floating point number if particular operations are undertaken: 656
int var1=5, var2=7, var3; 657 658 var3 = var2/var1; 659 -- This operation would fail as var3 is an integer and would contain the value 1, 660 661 float var4; 662 663 var4 = (float) var2/var1; 664 -- This operation will give the result 1.4 as the variables not treated as integers 665 666 However casting of data types is potentially dangerous, for example data will be truncated when the higher data type is 667
converted to lower, thus if a float is converted to int, data which is present after the decimal point will be lost. 668
669
670
671
ETSI
ETSI TR 103 534-1 V0.0.6 (2019-03)29
Annex G: 672
Guide to selecting a training provider 673
G.1 Overview 674
As part of best practice, it is important to also consider how security knowledge and expertise is disseminated and 675
developed. There are a number of recognised training and certification schemes described in this annex. All of them 676
address elements of the CIA paradigm, some with a broad-brush approach, some at a much more detailed level. 677
G.2 Certified Information Systems Security Professional 678
(CISSP) 679
680
Figure G.1: Topics in the CISSP examination by %-age of cover (from ISC2) 681
G.3 Cyber Security & Governance Certification Program 682
This certification program consists of 7 different certification tracks aligned based on the European e-Competence 683
Framework (e-CF). 684
ETSI
ETSI TR 103 534-1 V0.0.6 (2019-03)30
G.4 CompTIA Advanced Security Practitioner (CASP) 685
CompTIA's CASP - CompTIA Advanced Security Practitioner, is a vendor-neutral certification that validates IT 686
professionals with advanced-level security skills and knowledge. This certification course covers the technical 687
knowledge and skills required to conceptualize, design, and engineer secure solutions across complex enterprise 688
environments. It involves applying critical thinking and judgment across a broad spectrum of security disciplines to 689
propose and implement solutions that map to enterprise drivers, while managing risk. 690
G.5 Systems Security Certified Practitioner 691
SSCP is taught from the bottom up giving, it covers the following domains: 692
Access Controls 693
Security Operations and Administration 694
Risk Identification, Monitoring, and Analysis 695
Incident Response and Recovery 696
Cryptography 697
Network and Communications Security 698
Systems and Application Security 699
G.6 DevSecOps 700
The growing demand for faster software delivery using the strategies of agile and DevOps, with technologies such as 701
containers and the public cloud, has caused a rift between software production teams and security teams. Organizations 702
are realizing that putting security reviews at the end of a production cycle is not effective, because that often causes 703
security problems that could have been caught if security expertise had been involved from the design phase forward. 704
The best solution is to have security practices integrated into the entire software delivery cycle. But teams are still 705
reluctant, fearing that these practices will just be sand in the gears, making them unable to meet business demand for 706
DevOps-level speed. Security teams are also leery of trying to match pace with DevOps practices, since that would 707
involve using more automation—and security tooling hasn't always been up to the task [https://techbeacon.com/secure-708
devops-whats-it-dev-sec-ops]. 709
Secure DevOps, also referred to as DevSecOps or Rugged DevOps by practitioners, applies the same battle-tested 710
practices of DevOps to security practices. Just as developers and operations needed to start collaborating with one 711
another and understanding how their practices applied to the other side of the coin, security professionals also need to 712
understand how their practices can be applied in the development and production stages. Developers and operations 713
need to help facilitate this change by understanding more about what security teams do. 714
Security teams also need to apply another idea popularized by DevOps to their strategies—the idea of infrastructure as 715
code (IaC). The DevSecOps manifesto says the key to integrating security processes into DevOps is security as code 716
[http://www.devsecops.org]. 717
718
719
720
721
722
723
724
725
ETSI
ETSI TR 103 534-1 V0.0.6 (2019-03)31
Annex : 726
Bibliography 727
728
729
ETSI
ETSI TR 103 534-1 V0.0.6 (2019-03)32
Annex : 730
Change History 731
Date Version Information about changes
09-2018 0.0.1 Outline of document structure
09-2018 0.0.2 Post STF review inclusion of common text and some change in order of text sections
10-2018 to 01-2018
003/4 Initial restructuring internally to STF
03-2019 0.0.5 Stable draft proposal
732
733
ETSI
ETSI TR 103 534-1 V0.0.6 (2019-03)33
History 734
Document history
V0.0.1 09-2018 First draft of ToC and some outline content. Submitted for information to SmartM2M#47
V0.0.2 09-2018 Updated after STF547 internal review
V0.0.3 12-2018 Material moved from TR 103 533. New material added across the document
V0.0.4 01-2019 Rethinking after meeting with SmartM2M
V0.0.5 03-2019 Submission as stable draft
V0.0.6 03-2019. Extension of stable draft after STF review
735