text: www.enisa.europa.eu European Union Agency For Network and Information Security

text: IoT Security Standards Gap Analysis v1.0 | December 2018

text: Proposal for a REGULATION OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL on ENISA, the "EU Cybersecurity Agency", and repealing

text: Regulation (EU) 526/2013

text: , and on Information and Communication Technology cybersecurity certification ("Cybersecurity Act")

text: It should be underlined that this discussion is indicative and serve as an example, thus in no way implying any preference towards the use of CC or any other standard in the IoT domain. This would require a far more thorough analysis taking into account all related aspects and particularities, including the ones related to economics.

text: IoT Security Standards Gap Analysis

text: v1.0 | December 2018

text: IoT Security Standards Gap Analysis

text: v1.0 | December 2018

text: Figure B.1: Regular approach to producing a technical specification (ST or PP)

text: Fig. 2 Using a 'Direct rationale' approach to create technical specifications

text: See for example, collaborative Protection Profile for Full Drive 2 Encryption - Encryption Engine (https://www.commoncriteriaportal.org/files/ppfiles/CPP_FDE_EE_V2.0.pdf), collaborative Protection Profile for Full Drive Encryption – Authorization Acquisition v2.0 (https://www.commoncriteriaportal.org/files/ppfiles/CPP_FDE_AA_V2.0.pdf)

text: Figure B. 3 Composite product evaluation in the smart card environment Several constraints should be applied to the product development regarding conformity to take benefits from the re-use approach, but detailed discussion on this issue is outside the scope.

text: Figure B.4 Layered architecture of the IoT product with the concept of re-used evaluation results The concept of ‘root of trust’ establish a base for cost-efficient security evaluations based on previously certified HW or HW-SW components and thus creates a highly controlled environment to execute higher layers of the IoT device architecture.

text: The figure is adopted from Vetillard, E., Stütz, G., “Common Criteria as Backbone for IoT Security Certification”, the th 17 International Common Criteria Conference (ICCC) Amsterdam, 30 Oct – 01 Nov 2018

text: IoT Security Standards Gap Analysis

text: v1.0 | December 2018

identifier: IoT Security Standards Gap Analysis

amnesord: Artificial Intelligence and Next Gen Technologies

nummer: iot-security-standards-gap-analysis

title: IoT Security Standards Gap Analysis

text: Mapping of existing standards against requirements on security and privacy in the area of IoT

text: V1.0 DECEMBER 2018 About ENISA

text: The European Union Agency for Network and Information Security (ENISA) is a centre of network and information security expertise for the EU, its member states, the private sector and EU citizens. ENISA works with these groups to develop advice and recommendations on good practice in information security. It assists member states in implementing relevant EU legislation and works to improve the resilience of Europe’s critical information infrastructure and networks. ENISA seeks to enhance existing expertise in member states by supporting the development of cross-border communities committed to improving network and information security throughout the EU. More information about ENISA and its work can be found at www.enisa.europa.eu.

text: Contact

text: For queries in relation to this paper, please use isdp@enisa.europa.eu For media enquires about this paper, please use press@enisa.europa.eu.

text: Authors

text: Elżbieta Andrukiewicz Scott Cadzow

text: Sławomir Górniak

text: Legal notice Notice must be taken that this publication represents the views and interpretations of ENISA, unless stated otherwise. This publication should not be construed to be a legal action of ENISA or the ENISA bodies unless adopted pursuant to the

text: Regulation (EU) No 526/2013

text: . This publication does not necessarily represent state-of the-art and ENISA may update it from time to time.

text: Third-party sources are quoted as appropriate. ENISA is not responsible for the content of the external sources including external websites referenced in this publication.

text: This publication is intended for information purposes only. It must be accessible free of charge. Neither ENISA nor any person acting on its behalf is responsible for the use that might be made of the information contained in this publication.

text: Copyright Notice © European Union Agency for Network and Information Security (ENISA), 2018 Reproduction is authorised provided the source is acknowledged.

text: ISBN: 978-92-9204-275-2, DOI: 10.2824/713380

text: Table of Contents

text: Executive Summary 4

text: 1. General information 5 Background and objectives of the study 5 Scope of the study 5 Related documents 5 Applied methodology 6

text: 2. Analysis of standards gap 7

text: 3. The certification opportunity 8 Annex A: Mapping of requirements to standards 10 A.1 Role of standardisation 10 Gaps in standardisation 11 Annex B: Proposal for security standards evolution in IoT realm 23 Introduction 23 Conventional development of ST or PP 23 Direct rationale approach for creating simpler and faster specifications 24 Composite evaluations suitable for IoT devices 26

text: Executive Summary

text: ENISA conducts a preliminary analysis of the IoT-related landscape of standards, which indicates that there is no significant gap in standards to bring secure IoT to the market. This does not mean that the security of the IoT ecosystem as a whole has been addressed by means of standards. Elements of a holistic approach towards IoT security can be found in a series of standards, however to achieve an overarching approach that protects the entire IoT ecosystem further work is needed. Accordingly, given the particularity of the IoT ecosystem (e.g. very high scalability, context of use, short time to market and cost drivers), this study does not intend to promote a specific solution for the entire IoT. Conversely, by identifying and mapping the existing standards landscape for IoT security, the study aims at pinpointing potential areas of improvement and additional efforts in securing the IoT.

text: In general, there is an identifiable gap in process by which a vendor can assert that their IoT product or service is secure. On the assertion that standards enable interoperability, the lack of cohesion on the use and application of standards for secure IoT mean that interoperability is not guaranteed even if all devices were to be placed on the market with security features enabled.

text: The primary argument of the present document is that standards are essential but not sufficient to ensure open access to markets. In the particular case of security a large number of processes as well as technical standards have to be in place to ensure that any device placed on the market is assuredly secure. In this case the present document proposes, in Annex B, a theoretical approach towards a certification and assurance and validation scheme to identify what is sufficient, as a precursor to allow for market access through device, service and process certification. It should be noted that this approach is inherently theoretical, since it does not take into account relevant concerns such as economic considerations that might affect the viability of applying standards.

text: The process recommended in this document is intended in part to engender a change in attitude towards device security by making secure IoT the only form of IoT that reaches the market and to give confidence to the market through a mélange of certification, assurance testing & validation, and market surveillance.

text: The bulk of the material in the present report is contained in Annex A, the mapping of requirements to available standards, and in Annex B, a proposal for the technical basis of market certification.

text: 1. General information Background and objectives of the study

text: In 2017, ENISA defined a set of Baseline Security Recommendations for IoT. The aim of this work was to provide insight into the security requirements of IoT, mapping critical assets and relevant threats, assessing possible attacks and identifying potential good practices and security measures to apply in order to protect IoT systems.

text: Section 4 of this report – “Security measures and good practices” and Annex A – “Detailed Security measures / Good practices” provide requirements on security and privacy. These requirements were grouped and analysed in the context of standards available in each area, providing a mapping as the result.

text: In 2017 ENISA published a report “Gaps in NIS standardisation - Recommendations for improving NIS in EU standardisation policy”, available at https://www.enisa.europa.eu/publications/gaps-eu-standardisation The structure of that report has been considered as basis for this project.

text: The overall goal of the study is to map requirements on security and privacy in the area of IoT to existing standards, identifying the gaps.

text: Scope of the study

text: This study analyses the gaps and provides guidelines for, in particular, the development or repositioning of standards, facilitating the adoption of standards and governance of EU standardisation in the area of NIS. ENISA brings in this relationship its technical and organisational know-how in NIS which can be further leveraged into standards in terms of extending or assessing them to render them more appropriate to stakeholders and more compliant with the prevailing regulatory framework.

text: Special attention is given to the EU needs related to emerging cybersecurity certification schemes which will operate under the European cybersecurity certification framework. The framework is currently not adopted but is expected to be finished at the end of this year. Standards or other widely adopted technical specifications containing requirements form the basis for any certification activity. European standards for security evaluation models, methods, techniques and tools adopted to the IoT world are urgently needed to complement existing initiatives, good practices and industry guidelines on IoT security.

text: Related documents

text: The study is based on the following documents:

text: [1] ROLLING PLAN FOR ICT STANDARDISATION 2018, https://ec.europa.eu/growth/content/2018rolling-plan-ict-standardisation-released_en [2] Baseline Security Recommendations for IoT, Nov 20, 2017, https://www.enisa.europa.eu/publications/baseline-security-recommendations-for-iot

text: Applied methodology

text: Several widely recognized standardization organizations have been surveyed to create a matrix which combines subsequent requirements from Annex A of [2] and relevant standards.

text: Based on the analysis of leading standardization activities in the field of IoT given in [1], the matrix contains inputs from:

text:  Three European Standardization Organizations (ESO) ie. CEN, CENELEC and in particular ETSI TC Cyber  ISO/IEC JTC1 subcommittees including SC27 (IT Security Techniques) and SC41 (Internet of Things and related technologies)  ITU-T SERIES Y: GLOBAL INFORMATION INFRASTRUCTURE, INTERNET PROTOCOL ASPECTS AND NEXT-GENERATION NETWORK.

text: The outcome is given in Annex A2.

text: 2. Analysis of standards gap

text: The requirements listed in the ENISA report “Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures” have been mapped to an existing identifiable standard that if followed would allow the requirement to be satisfied. The detailed, requirement by requirement, mapping is given in Annex A.

text: The simplified analysis yields that there is no significant standards gap - every requirement can be met by an existing standard. The problem is that this is neither the correct nor the expected answer. Standards exist for many different elements of making a device or service secure. However, when referring to IoT, one refers to an ecosystem of not only devices and services. Moreover, the context of use of IoT, its high scalability and other particularities further complicate the field and require more generic and flexible approaches. Therefore, for example the gap in IoT device standards for security is that the standards are not treated holistically so it is possible to deliver a device to the market that can authenticate its user, that can encrypt data it transmits, that can decrypt data it receives, that can deliver or verify the proof of integrity, but which will still be insecure. Similarly, the organisation developing the IoT product or service may have the development processes defined in management guidelines such as those of ISO-27000 but still delivers an insecure product.

text: The challenge for regulators and suppliers alike is to bring only secure IoT devices to the market and this requires a different approach, which will have to be flexible enough to accommodate for the nature of the dynamic IoT ecosystem. Accepting that it is often speculation, there is a necessary challenge to imagine how society will be in a few years from now and to consider the threats to society at that time. In order to frame this, the broad assumption is that ICT will reach further into society with more connectivity, further augmentation of everyday life through ICT, and this will demand an ICT and cybersecurity response. The concerns of the next few years however stretch far beyond the remit of only security technology and many of the recommendations in the present document extend to gaining better understanding of the societal understanding of how ICT, and in particular, ICT incorporating cybersecurity impacts daily life.

text: Whereas this checklist of security requirements for IoT security and its mapping to specific standards can serve as a springboard towards holistic and effective IoT security, it should be noted that the intricacies of the IoT ecosystem call for more flexible approaches. Not only are the underlying technological challenges calling for adaptive, context- and risk-based solutions, but also the IoT market constraints have to be taken into account, so as not to hamper competitiveness and innovation.

text: 3. The certification opportunity

text: The overall purpose of standards from the perspective of the market is twofold in defining what a standard is intended to achieve: (1) interoperability, and (2) confidence.

text: The conventional role of standards in achieving interoperability is discussed in some length in Annex A and is not repeated here.

text: The role of standards in the domain of trust is less well defined and in a security context is difficult to state in simple terms. When referring to the IoT, one should not only consider individual devices. The inherent connectivity and interdependencies of devices, services, people, process and data call for holistic approaches. Accordingly, this implies a much more holistic view of the role of the device as opposed to a relatively closed view of what standard does it comply to for say encryption.

text: Standards can be used for developing technical specifications in a specific context of a product type, and provide a framework for security evaluation of products. Such general concept is presented in the figure below.

text: As a representative use case example, we discuss here the case of the international standard ISO/IEC 15408 Evaluation criteria for IT security, widely recognized as ‘Common Criteria’ (CC) . CC consists of 3 parts including:

text:  Part 1: Introduction and general model  Part 2: Security functional components  Part 3: Security assurance components

text: Based on the security model discussed in part 1 one can develop technical specifications, called – in CC language – ‘protection profiles’ (PP) for the product type, or ‘security target’ (ST) for a given product. Such specifications contain security requirements according to the formal taxonomy given in part 2 of CC, and

text: simultaneously create the evaluation requirements by using security assurance components given in part 3 of CC.

text: The evolution of CC from PP/ST through cPPs (collaborative Protection Profiles) and into the proposed “Direct Rationale” approach from the Common Criteria group does provide a framework for a wider, holistic view of security and therefore of confidence. The “Direct Rationale” approach provides a way of producing comprehensive security specifications for products, which is simpler than a traditional one hence it could be potentially applied in the IoT for preparing good technical specifications, giving simultaneously the ground for providing requiring solid and proven confidence the product meets security requirements.

text: The opportunity to drive market confidence in security of IoT may be developed from the work outlined in evolution of the Common Criteria (see also a detail examination in Annex B) to propose to all ICT security developing SDOs, to work towards cPPs and from there to work in the Direct Rationale cPP development.

text: Evidently, the example use case of CC can be considered for other standards when it comes to IoT. As mentioned, there is a growing call for flexible and adaptive solutions in this environment and therefore a complete analysis is beyond the scope of this report.

text: There is an opportunity to develop standards that have to be testable and that will be cited in the certification chain as proof of assurance. A subtle assertion is that if you comply with a standard, and that standard is properly maintained, then conformance is sufficient. Less obvious is that the proof of security assurance will require many standards to be conformed to.

text: Annex A: Mapping of requirements to standards A.1 Role of standardisation A.1.1 General overview

text: In the context of IoT devices, a broad generalisation of the role of standards is that their role is to provide interoperability of "things". It is also a broad generalisation that standards provide requirements to be met and do not provide instructions on how to implement a requirement. For security standards these statements apply as a broad interpretation but with the slight modification that many security standards, or more likely the security functions defined in standards, give assurance of the interoperability of "things" when subject to attack by hostile parties. Thus standards may address functionality (e.g. an encryption algorithm), application of that functionality (e.g. use of specific encryption mode (say counter mode)), and contextual use of that functionality (e.g. application of encryption to provision of confidentiality protection services).

text: Entities involved in cryptographic security that are required to interoperate will also require sharing knowledge and functionality that will include the identification of keys and algorithms. Thus security standards have to address simple mechanical interconnection, semantic and syntactic shared meaning, and management of attributes and organisations to react to security transgressions in an appropriate manner.

text: A.1.2 Organisational interoperability

text: There is a class of organisational management standards in security that defines roles within organisations that seek to enforce a "need to know". From a security perspective when two organisations share data they may transfer data securely by having a common Communications Security (ComSec) framework, but the ComSec exchange cannot make any inference on how data is treated prior to, or after, transfer. Thus the local IT security policy of the sending and receiving organisations is trusted to be equivalent and this trust may be reinforced by external measures.

text: A.1.3 Syntactic interoperability

text: Syntax derives from the Greek word meaning ordering and arrangement. The English language sentence structure of subject-verb-object is a simple example of syntax, and generally in formal language syntax is the set of rules that allows a well formed expression to be formed from a fundamental set of symbols. In computing science syntax refers to the normative structure of data. In order to achieve syntactic interoperability there has to be a shared understanding of the symbol set and of the ordering of symbols. In any language the dictionary of symbols is restricted, thus in general a verb should not be misconstrued as a noun for example (although there are particularly glaring examples of misuse that have become normal use, e.g. the use of "medal" as a verb wherein the conventional text "He won a medal" has now been abused as "He medalled").

text: A.1.4 Semantic interoperability

text: Syntax cannot convey meaning and this is where semantics is introduced. Semantics derives meaning from syntactically correct statements. Semantic understanding itself is dependent on both pragmatics and context. There are a number of ways of exchanging semantic information although the success is dependent on structuring data to optimise the availability of semantic content and the transfer of contextual knowledge (although the transfer of pragmatics is less clear). The most obvious examples of semantic containers for syntactically correct information are protocols whereby the protocol (e.g. an

text: authentication protocol) gives context to message sets. This may be further extended using the concept of shared state as a means of identifying context and this is often embedded in protocol (e.g. an authentication protocol may go through states that include "Identified", "Challenge issued", "Response pending" prior to finalising on the state "Authenticated").

text: A.1.5 Electrical and mechanical interoperability

text: Quite simply a device with a power connector using, for example, a Type IEC 60906-2 connection cannot accept power from anything other than a Type IEC 60906-2 connector. Similarly, for example, a serial port complying to USB-Type-A will not be able to connect with a USB-Type-C lead. In addition to simple mechanical compatibility there is a requirement to ensure electrical interoperability covering amongst others the voltage level, amperage level, DC or AC, frequency if AC, variation levels and so forth.

text: A.1.6 Radio communication interoperability

text: Radio (wireless) communication requires shared knowledge of frequency band, modulation technique, symbol rate, power, and so forth. In general radio communication can be characterised as broadcast and unreliable. The nature of the physical media requires that radio protocols make provisions to maximise link reliability, most often achieved using various forms of Forward Error Correction in the Link Layer (layer 2 of the OSI stack).

text: Gaps in standardisation

text: It is recognised that whilst there are a very large number of bodies that develop standards it is also recognised that most service providers, manufacturers and governments are involved in a significant number of them. This unfortunately also means that as each standards body is in competition with each other, that there is overlap in capability and of itself this constitutes a risk to security.

text: ASSERTION: Gaps in standards present risk that additional standardisation effort may mitigate, but overlaps in standardisation effort present risk that may not be mitigated by additional standardisation effort but rather by agreed reduction, or redaction of existing standards.

text: TABLE A.1: MAPPING OF REQUIREMENTS TO AVAILABLE STANDARDS

text: Standards in support of Req. ID Statement of requirement requirement

text: Security by Design

text: Consider the security of the whole IoT system from a consistent and holistic approach during its whole lifecycle ISO 30141 clause 11.3.3, ITU Y.4806 GP-PS-01 across all levels of device/application design and Security capabilities supporting development, integrating security throughout the safety of the Internet of things development, manufacture, and deployment.

text: Ensure the ability to integrate different security policies GP-PS-02 ISO 30141 clause 11.3.2 and techniques.

text: GP-PS-03 Security must consider the risk posed to human safety. ISO 30141 clause 11.2

text: Designing for power conservation should not compromise GP-PS-04 n/a security.

text: Design architecture by compartments to encapsulate GP-PS-05 ISO 30141 clause 11.3.2 elements in case of attacks.

text: ISO/IEC 15408-3 (ATE and AVA Classes description) For IoT hardware manufacturers and IoT software May be addressed in part by developers it is necessary to implement test plans to independent assurance testing verify whether the product performs as it is expected. GP-PS-06 against documented security claims. Penetration tests help to identify malformed input The role of penetration testing is handling, authentication bypass attempts and overall often prohibited, or restricted, by security posture. legislation (e.g. the Computer Misuse Act).

text: ISO/IEC 15408-3 (ATE Class description) Whilst this is not directly mappable to standards there are quality For IoT software developers it is important to conduct practices that may impose code GP-PS-07 code review during implementation as it helps to reduce review. In addition many coding bugs in a final version of a product. practice guidelines will explicitly address means to perform code reviews, and many frameworks will explicitly identify when a codereview should be performed.

text: Apple secure development guidelines, from https://developer.apple.com/library /content/documentation/Security/C onceptual/SecureCodingGuide/Intro duction.html Microsoft Security Development Lifecycle (SDL) from https://www.microsoft.com/enus/sdl Open Software Assurance Maturity Model (SAMM) from http://www.opensamm.org Building Security in Maturity Model (BSIMM), incorporating the SSDL method, from https://www.bsimm.com

text: NOTE: For each of the above, particularly GP-PS-05 and GP-PS-07. there exist some best practice guidelines for specific developer environments.

text: Privacy by Design

text: GP-PS-08 Make privacy an integral part of the system ISO 29550

text: NOTE: It is noted that a breach of privacy requires at least one actor to perform the breach. The GDPR recommendation to undertake a DPIA when applied would restrict breaches to explicit breaking of any measures applied or to specific actions by actors at the edge of the system.

text: ISO/IEC 27005, ISO/IEC 29134. ISO 27005 defines a method of Perform privacy impact assessments before any new GP-PS-09 conducting a PIA. It is noted that applications are launched GDPR requires that a DPIA/PIA is performed

text: ETSI TS 103 305 (from controls from CIS). Establish and maintain asset management procedures ISO/IEC 27002 clause 8.1 may apply GP-PS-10 and configuration controls for key network and in selection of controls with other information systems parts of the ISO 27002 ISO 55000 Asset management

text: Military standards such as below Identify significant risks using a defence-in-depth GP-PS-11 may apply. In general there are no approach standards that define the defence in

text: depth approach although it is an accepted best practice of most security professionals

text: https://www.iad.gov/iad/customcf/openAttachment.cfm?FilePath=/iad/library/iaguidance/archive/assets/public/upload/Defense-in- Depth.pdf&WpKes=aF6woL7fQp3dJiLgJBSABf7qwgxHD5mzFWdTgW

text: Required in development of a risk analysis in defining the scope of security evaluation (the ToE in Identify the intended use and environment of a given IoT ISO/IEC 15408-1 and -2)). GP-PS-12 device Addressed in some IoT best practices including the (soon to be published) ETSI TS 103 645.

text: Organisational, People and Process measures

text: ISO 30141 clause 11.3.3 (IoT system & product Security Life Cycle GP-OP-01 Develop an end-of-life strategy for IoT products Reference Model)Addressed in TS 103 645 and in ETSI TR 103 533.

text: ISO 30141 clause 11.3.3 (IoT system Disclose the duration and end-of-life security and patch & product Security Life Cycle GP-OP-02 support (beyond product warranty) Reference Model)Addressed in TS 103 645 and in ETSI TR 103 533.

text: ISO 30141 clause 11.3.3 (IoT system Monitor the performance and patch known & product Security Life Cycle GP-OP-03 vulnerabilities up until the “end-of-support|” period of a Reference Model)Addressed in TS product’s lifecycle 103 645 and in ETSI TR 103 533.

text: ISO 27002 clause 10 ISO 11770 (key management) Series of standards ISO/IEC 29192 Use proven solutions, i.e. well known communications (Lightweight cryptography – 7 parts, protocols and cryptographic algorithms, recognized by covering algorithms and protocols) GP-OP-04 the scientific community, etc. Certain proprietary solutions, such as custom cryptographic algorithms, Not specifically addressed in should be avoided standards. The reason is that standards by design are built on proven solutions and conforming to standards addresses this.

text: Establish procedures for analysing and handling security ISO 27002 16Addressed in TS 103 GP-OP-05 incidents 645 and in ETSI TR 103 533.

text: ISO/IEC 301111 (Addressed in TS 103 645 and in ETSI TR 103 533. In addition the use of Common GP-OP-06 Coordinated disclosure of vulnerabilities Vulnerability handling processes) and Disclosure (ISO/IEC 29147 (Vulnerability disclosure)) applies.

text: ISO 27002 6.1.3 ISO 27002 6.1.4 Addressed in TS 103 645 and in ETSI TR 103 533. Participate in information-sharing platforms to report In addition the use of Common vulnerabilities and receive timely and critical information Vulnerability Disclosure (ISO/IEC GP-OP-07 about current cyber threats and vulnerabilities from 29147) applies. public and private partners It is also noted in a number of regulatory instruments (GDPR, NIS, …) that common use of the CERT framework is expected.

text: ISO/IEC 301111 (Vulnerability handling processes) and 29147 (Vulnerability disclosure)Addressed in TS 103 645 and in ETSI TR 103 533. Create a publicly disclosed mechanism for vulnerability Some vendors provide financial GP-OP-08 reports, e.g. Bug Bounty <tba>programs incentives and this has to be considered (it may be argued that if a financial incentive is offered then bug hunters may be more incentivised than if no such incentive applies).

text: Ensure the personnel practices promote privacy and GP-OP-09 security – train employees in good privacy and security ISO 27002 clause 7.2 practices

text: Document and monitor the privacy and security training GP-OP-10 ISO 27002 clause 7.2.2 activities

text: Ensure that cybersecurity roles and responsibilities for all workforce are established and introduce personnel GP-OP-11 ISO 27002 clause 7.2.1 assignments in accordance with the specifics of the projects and security engineering needs

text: Data processed by a third-party must be protected by a GP-OP-12 ISO 27002 clause 13.2.4, clause 15 data processing agreement

text: ISO 27002 clause 18.1.4 Only share consumers’ personal data with third parties This is a key constraint of the GDPR with express consent of the consumers, unless otherwise GP-OP-13 and is specifically addressed in required and limited for the use of product features or

text: Article 6

text: for the lawful processing of service operations data.

text: For IoT hardware manufacturers and IoT software developers it is necessary to adopt cyber supply chain risk GP-OP-14 ISO 27002 clause 15 management policies and to communicate cyber security requirements to its suppliers and partners

text: Technical measures

text: TPM from TCG (published as ISO/IEC GP-TM-01 Employ a hardware-based immutable root of trust 11889) SIM from ETSI SCP

text: Use hardware that incorporates security features to strengthen the protection and integrity of the device – for example, specialised security chips / coprocessors that integrate security at the transistor level, embedded in the processor, providing, among other things, a trusted TPM from TCG (published as ISO/IEC GP-TM-02 storage of device identity and authentication means, 11889) protection of keys at rest and in use, and preventing unprivileged from accessing to security sensitive code. Protection against local and physical attacks can be covered via functional security

text: Trust must be established in the boot environment Secure boot, Defined by TCG GP-TM-03 before any trust in any other software or executable (published as ISO/IEC 11889) program can be claimed

text: Series of standards ISO/IEC 29192-5 Sign code cryptographically to ensure it has not been and 6 (Lightweight cryptography – tampered with after signing it as safe for the device, and Part 5: Hash-functions, Part 6: GP-TM-04 implement run-time protection and secure execution Message authentication codes monitoring to make sure malicious attacks do not (MACs), ITU X.1362 Simple overwrite code after it is loaded ecryption procedure for IoT environments

text: ISO 27002 clause 12.6.2. This is covered by techniques including Control the installation of software in operating systems, load time attestation, boot time GP-TM-05 to prevent unauthenticated software and files from being attestation and run time loaded onto it attestation. Many of these techniques are built on TPMs (published as ISO/IEC 11889). In

text: addition the ETSI GR NFV-SEC-007 gives broad guidance to this topic.

text: Enable a system to return to a state that was known to be GP-TM-06 secure, after a security breach has occurred or if an ISO 27002 clause 12.3 upgrade has not been successful

text: In general for cryptographic trust the mechanisms inherent in X.509 Use protocols and mechanisms able to represent and apply, with additional protocol GP-TM-07 manage trust and trust relationships mechanisms to transfer X.509 certificates such as those in TLS apply.

text: ISO/IEC 15408-1 and -2Addressed in TS 103 645 and in ETSI TR 103 533. Any applicable security features should be enabled by It is noted that if the secure by GP-TM-08 default, and any unused or insecure functionalities should default approach is selected there be disabled by default will be no requirement to disable insecure functionalities as they will not exist.

text: ISO 27002 clause 9.2.4. This is not a recommended approach as the use Establish hard to crack, device-individual default of default passwords should be GP-TM-09 passwords avoided. Addressed in TS 103 645 and in ETSI TR 103 533

text: ISO 27002 18.1.4 ISO 29100 ISO/IEC 29184 Online privacy notice and consent Personal data must be collected and processed fairly and ISO 30141 clause 11.4 (Privacy and GP-TM-10 lawfully, it should never be collected and processed PII Protection). This is a prewithout the data subject’s consent requisite in GDPR (

text: Article 6

text: applies). Regarding consent not all parts of

text: Article 6

text: apply (consent is not the only path to allow for lawful processing).

text: Make sure that personal data is used for the specified This is a pre-requisite in GDPR purposes for which they were collected, and that any GP-TM-11 further processing of personal data is compatible and ISO 29100. that the data subjects are well informed

text: This is a pre-requisite in GDPR GP-TM-12 Minimise the data collected and retained ISO 29100.

text: IoT stakeholders must be compliant with the EU General GP-TM-13 No standardisation applies. Data Protection Regulation (GDPR)

text: GDPR ISO 29100 Users of IoT products and services must be able to ISO 30141 11.4 exercise their rights to information, access, erasure, (ea: other PII standards to be GP-TM-14 rectification, data portability, restriction of processing, identified)No specific standards objection to processing, and their right not to be apply. There are obligations from evaluated on the basis of automated processing GDPR that address this and some ETSI best practices are being developed.

text: Design with system and operational disruption in mind, GP-TM-15 preventing the system from causing an unacceptable risk ISO 27002 17.1.1 of injury or physical damage

text: ISO 27031 (guidelines for Mechanisms for self-diagnosis and self-repair/healing to information and communication GP-TM-16 recover from failure, malfunction or a compromised state technology readiness for business continuity)

text: ISO 27031 (guidelines for information and communication Ensure standalone operation - essential features should technology readiness for business continue to work with a loss of communications and continuity)By default an IoT device GP-TM-17 chronicle negative impacts from compromised devices or cannot operate in stand-alone cloud-based systems mode, it is designed to be tethered to the Internet. This introduces a new mode to the IoT device.

text: Ensure that the device software/firmware, its configuration and its applications have the ability to update Over-The-Air (OTA), that the update server is secure, that the update file is transmitted via a secure connection, that it does not contain sensitive data (e.g. Addressed in TS 103 645 and in ETSI GP-TM-18 hardcoded credentials), that it is signed by an authorised TR 103 533. trust entity and encrypted using accepted encryption methods, and that the update package has its digital signature, signing certificate and signing certificate chain, verified by the device before the update process begins

text: Addressed in best practice guidance GP-TM-19 Offer an automatic firmware update mechanism from ETSI and others

text: Backward compatibility of firmware updates. Automatic firmware updates should not modify user-configured Addressed in best practice guidance GP-TM-20 preferences, security, and/or privacy settings without from ETSI and others user notification

text: 29192 CD Lightweight cryptography --Part 7: Broadcast Requires a system wide threat analysis. Approaches to such threat Design the authentication and authorisation schemes analysis include ETSI TS 102 165-1, GP-TM-21 (unique per device) based on the system-level threat ISO27000 series, ISO15408 series models and others for specific sectors. Frameworks for authentication protocol and authorisation schemes are defined in ETSI TS 102 165-2 and in ISO/IEC 29115.

text: ISO 27002 9.2.4, Ensure that default passwords and even default ISO 27002 9.4.2 GP-TM-22 usernames are changed during the initial setup, and that ISO 27002 9.4.3 weak, null or blank passwords are not allowed Addressed in TS 103 645 and in ETSI TR 103 533.

text: Authentication mechanisms must use strong passwords or personal identification numbers (PINs), and should ISO/IEC 19790 Security GP-TM-23 consider using two-factor authentication (2FA) or multi- requirements for cryptographic factor authentication (MFA) like Smartphones, modules Biometrics, etc., on top of certificates

text: ISO/IEC 19790 Security Authentication credentials shall be salted, hashed and/or GP-TM-24 requirements for cryptographic encrypted modules

text: Protect against ‘brute force’ and/or other abusive login ISO/IEC 19790 Security GP-TM-25 attempts. This protection should also consider keys requirements for cryptographic stored in devices modules

text: Ensure password recovery or reset mechanism is robust ISO/IEC 19790 Security and does not supply an attacker with information GP-TM-26 requirements for cryptographic indicating a valid account. The same applies to key modules update and recovery mechanisms

text: Limit the actions allowed for a given system by Implementing fine-grained authorisation mechanisms No standards apply. Best practice GP-TM-27 and using the Principle of least privilege (POLP): requirement applications must operate at the lowest privilege level possible

text: Device firmware should be designed to isolate privileged code, processes and data from portions of the firmware No standards apply. Best practice GP-TM-28 that do not need access to them. Device hardware should requirement provide isolation concepts to prevent unprivileged from accessing security sensitive code

text: Data integrity and confidentiality must be enforced by access controls. When the subject requesting access has GP-TM-29 ISO 27002 9 been authorised to access particular processes, it is necessary to enforce the defined security policy

text: Ensure a context-based security and privacy that reflects GP-TM-30 ISO 27002 8.2 different levels of importance

text: Measures for tamper protection and detection. Detection ISO/IEC 19790 Security GP-TM-31 and reaction to hardware tampering should not rely on requirements for cryptographic network connectivity modules

text: ISO/IEC 19790 Security Ensure that the device cannot be easily disassembled and requirements for cryptographic GP-TM-32 that the data storage medium is encrypted at rest and modules, ITU-T Y.4415 Reference cannot be easily removed architecture for IoT device capability exposure

text: Ensure that devices only feature the essential physical external ports (such as USB) necessary for them to function and that the test/debug modes are secure, so ISO/IEC 15408-2 (to be further GP-TM-33 they cannot be used to maliciously access the devices. In investigated) general, lock down physical ports to only trusted connections

text: Ensure a proper and effective use of cryptography to protect the confidentiality, authenticity and/or integrity of data and information (including control messages), in GP-TM-34 transit and in rest. Ensure the proper selection of ISO 27002 10 standard and strong encryption algorithms and strong keys, and disable insecure protocols. Verify the robustness of the implementation

text: GP-TM-35 Cryptographic keys must be securely managed See GP-Op-04

text: Build devices to be compatible with lightweight GP-TM-36 See GP-Op-04 encryption and security techniques

text: No specific standards apply. Best GP-TM-37 Support scalable key management schemes practice requirement

text: ISO 27002 5

text: ISO 27034 (application security) Guarantee the different security aspects -confidentiality

text: (privacy), integrity, availability and authenticity- of the ISO 27033 (network security) GP-TM-38 information in transit on the networks or stored in the ISO 27040 (storage security) IoT application or in the Cloud

text: ISO 27017 ( 27002 for cloud

text: services)

text: Ensure that communication security is provided using No specific standards apply. Best GP-TM-39 state-of-the-art, standardised security protocols, such as practice requirement TLS for encryption

text: Ensure credentials are not exposed in internal or external ISO/IEC 15408-2 (to be further GP-TM-40 network traffic investigated)

text: Guarantee data authenticity to enable reliable exchanges

text: from data emission to data reception. Data should always ISO/IEC 15408-2 (to be further GP-TM-41 be signed whenever and wherever it is captured and investigated)

text: stored

text: Do not trust data received and always verify any

text: interconnections. Discover, identify and ISO/IEC 15408-2 (to be further GP-TM-42 verify/authenticate the devices connected to the network investigated) before trust can be established, and preserve their

text: integrity for reliable solutions and services

text: IoT devices should be restrictive rather than permissive in GP-TM-43 Best practice requirement communicating

text: Make intentional connections. Prevent unauthorised ISO/IEC 15408-2 (to be further GP-TM-44 connections to it or other devices the product is investigated) connected to, at all levels of the protocols

text: Disable specific ports and/or network connections for ISO/IEC 15408-2 (to be further GP-TM-45 selective connectivity investigated)

text: Rate limiting. Controlling the traffic sent or received by a No specific standards apply. Best GP-TM-46 network to reduce the risk of automated attacks practice requirement

text: Risk Segmentation. Splitting network elements into ISO/IEC 27033 Network security (6 GP-TM-47 separate components to help isolate security breaches parts) and minimise the overall risk

text: Protocols should be designed to ensure that, if a single No specific standards apply. Best GP-TM-48 device is compromised, it does not affect the whole set practice requirement

text: Avoid provisioning the same secret key in an entire ISO/IEC 15408-2 (to be further GP-TM-49 product family, since compromising a single device would investigated) be enough to expose the rest of the product family

text: No specific standards apply. Best GP-TM-50 Ensure only necessary ports are exposed and available practice requirement

text: Implement a DDoS-resistant and Load-Balancing No specific standards apply. Best GP-TM-51 infrastructure practice requirement

text: Ensure web interfaces fully encrypt the user session, from No specific standards apply. Best GP-TM-52 the device to the backend services, and that they are not practice requirement susceptible to XSS, CSRF, SQL injection, etc

text: ISO/IEC 15408-2 (to be further GP-TM-53 Avoid security issues when designing error messages investigated)

text: Data input validation (ensuring that data is safe prior to ISO/IEC 15408-2 (to be further GP-TM-54 use) and output filtering investigated)

text: Implement a logging system that records events relating

text: to user authentication, management of accounts and

text: access rights, modifications to security rules, and the ISO/IEC 15408-2 (to be further GP-TM-55 functioning of the system. Logs must be preserved on investigated)

text: durable storage and retrievable via authenticated

text: connections

text: Implement regular monitoring to verify the device No specific standards apply. Best GP-TM-56 behaviour, to detect malware and to discover integrity practice requirement errors

text: Conduct periodic audits and reviews of security controls

text: GP-TM-57 to ensure that the controls are effective. Perform ISO 27002 12

text: penetration tests at least biannually

text: Annex B: Proposal for security standards evolution in IoT realm Introduction

text: As has been suggested in the main body of the present document there is a gap in standards only insofar as it is unclear what combination of standards, when applied to a product, service or system, will result in a recognizably secure IoT. The proposal presented below is to develop a processthat alongside some certification marking on IoT products and services, that gives assurance to the market that the IoT product is as secure as can be reasonably expected. As an example of how this process could work, we consider the case of Common Criteria (standardized in ISO/IEC 15408). It should be noted that this example does not imply that CC is an optimal or preferred approach in the context of IoT and serves only as an example to illustrate the generic process.

text: Accordingly, the overall concept is intended to build from best practice in evaluation of security claims that derive from the Common Criteria and to ensure that developers address how security claims will be evaluated both by professional evaluators and by the market. In the past (from 2010 roughly) ETSI has promoted a paradigm of “design for assurance” that has considered this form of development to ensure that developers undertake a risk analysis and provide a rationale for every security mechanism standardized for a product or service, whilst making clear the security claims of the protocol.

text: Conventional development of ST or PP

text: ISO/IEC 15408-1 contains detailed guidance on the development of technical specifications in the form of general description of the product type, called Protection Profile (PP) or dedicated one, called Security Target (ST). A product that is then characterized as a Target of Evaluation (ToE) and which has been developed according to content of either an ST or a PP could be the subject for further security evaluation. If an evaluator agrees that the ToE (the product) conforms to the claims made in the ST/PP then it is reasonable to claim the ToE (the product) is secure within the constraints described in the ST/PP. The process of developing security requirement for the ST/PP encompass several steps which are presented in Figure B.1 (numbers indicate steps in the process of producing the specification).

text: The outcome of this process usually results in a lengthy technical specification which is difficult to understand for non-experienced users.

text: The idea of simplification of this time- and resource consuming process is present in the current version of ISO/IEC 15408-1 under the name of ‘low assurance’ ST/PP. However, its usage is restricted to the lowest level of assurance, i.e. EAL1 and only briefly discussed in the standard.

text: In a revised version of ISO/IEC 15408-1 the concept of ‘low assurance’ is replaced with a ‘direct rationale’ one. However, it is not only changing the name but the approach as well. The direct rationale is now one of the type of PP/ST with simplifying method of creating specifications. Moreover, it is not restricted to low assurance packages but can request a higher level of assurance.

text: Direct rationale approach for creating simpler and faster specifications

text: By definition, ‘direct rationale’ means a type of Protection Profile or Security Target in which the Security Problem Definition (SPD) elements (i.e. of Assumptions, Threats and Organizational Security Policies) are mapped directly to the Security Functional Requirements (SFRs) and, possibly Security Objectives for the operational environment (see Figure B.2).

text: A Direct Rationale ST has all the following differences compared to a regular ST:

text:  no Security Objectives for the TOE are described. The Security Objectives for the operational environment must still be described;  there is no Security Objectives rationale as there are no TOE Security Objectives in the ST;  there is a requirement to provide natural language description of the SFRs and their relationship to security functionality regarding the architecture that is visible to Administrators and other users;  the security requirements rationale directly maps the elements of the SPD to the SFRs and the Security Objectives for the operational environment.

text: A Direct Rationale PP has the same simplifications about a regular PP like a Direct Rationale ST to a regular ST.

text: Several ‘direct rationale’ PPs exist and are in use as a base for Direct Rationale ST.

text: In the case of Direct Rationale ST/PP, Security Assurance Requirements (SARs) are usually not related to pre-defined Evaluation Assurance Levels (EALs). Instead of, there is a list of specific assurance components suitable for the specification. When the TOE is evaluated, there is no need to check every assurance

text: component from the package. Such an approach could make evaluations faster and more cost-efficient than traditional ones.

text: In specific contexts, applicable to simple devices or products with a short Time-to-Market parameter or intended to be produced on a massive scale, the direct rationale approach could be a useful solution.

text: Composite evaluations suitable for IoT devices

text: The revised ISO/IEC 15408 series of standards also provides flexible approaches to evaluations, which could be potentially prove to be suitable for the IoT world. This approach is called a ‘composite evaluation’. The composite evaluation takes place where one considers a product comprised of two or more components which can be organized in two layers: a layer of autonomous base component(s) and a layer of dependent components. The composite evaluation can be applied as many times as necessary to a multi-component/multi-layered product, in an incremental approach.

text: The composite product evaluation meets different types of objectives:

text:  independently perform one evaluation of a platform to address several applications and customers;  create one or several applications to load on one or several certified platforms;  install one or several applications onto one already certified platform to reduce the evaluation effort keeping a high level of confidence.

text: Composite evaluations have been developed for the smart card world as shown in Figure B.3 and appeared to be the most successful implementation of the CC certifications. Such an approach allows developers and evaluators to re-use results from previous evaluations thus reduce the time and cost the current one.

text: Considering layered architecture of certain IoT devices the composite evaluation approach introduced in the revised version of ISO/IEC 15408-1 could be under circumstances seen to be applicable to the IoT world.

text: A general architecture of an IoT device concerning the composite evaluation is presented in Figure B.4.

text: ENISA

text: European Union Agency for Network and Information Security 1 Vasilissis Sofias Marousi 151 24, Attiki, Greece

text: Heraklion Office

text: Science and Technology Park of Crete (ITE) Vassilika Vouton, 700 13, Heraklion, Greece Catalogue Number TP-07-18-076-EN-N

text: 1 Vasilissis Sofias Str, Maroussi 151 24, Attiki, Greece ISBN: 978-92-9204-275-2 DOI: 10.2824/713380 Tel: +30 28 14 40 9710 info@enisa.europa.eu www.enisa.europa.eu


text: Flash Note 02, 24th February 2014

text: European Union Agency for Network and Information Security

text: Flash Note 02, 24th February 2014

text: http://threatpost.com/high-volume-ddos-attacks-top-operational-threat-to-businesses-serviceproviders/103933 http://www.enisa.europa.eu/publications/flash-notes/flash-note-can-recent-attacks-really-threateninternet-availability http://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse https://labs.ripe.net/Members/mirjam/ntp-reflections http://www.us-cert.gov/ncas/alerts/TA14-013A

text: http://blog.cloudflare.com/technical-details-behind-a-400gbps-ntp-amplification-ddos-attack https://www.trusted-introducer.org/news/TI-info-spreading.html http://shodanio.wordpress.com/2014/01/27/analyzing-ntp-usage-on-the-internet-with-shodan/ http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-5211 https://www.cert-bund.de/advisoryshort/CB-K14-0020%20UPDATE%202 http://blogs.cisco.com/security/a-smorgasbord-of-denial-of-service/ http://www.iss.net/security_center/reference/vuln/Chargen_Denial_of_Service.htm https://www.cert.be/pro/docs/chargensnmp-ddos-attacks-rise https://www.us-cert.gov/ncas/alerts/TA14-017A http://tools.ietf.org/html/bcp38 http://tools.ietf.org/html/rfc3704 http://www.circl.lu/pub/tr-19/ http://openntpproject.org/ https://www.team-cymru.org/ReadingRoom/Templates/secure-ntp-template.html http://support.ntp.org/bin/view/Main/SecurityNotice#DRDoS_Amplification_Attack_using

identifier: Flash Note: Large scale UDP attacks - the 2014 trend and how to face it

publisher: Europeiska unionens cybersäkerhetsbyrå

sprak: en

serie: rapporter

text: Large scale UDP attacks: the 2014 trend and how to face it

type: stycke

type: rubrik

text: Recent news show the increase of large scale attacks exploiting specific vulnerabilities of the Internet core protocols. In the latest cases, the Network Time Protocol (NTP), which allows synchronizing devices to the coordinated universal time (UTC), has been misused. Specifically, in December 2013, a vulnerability in this UDP protocol became mainstream and started to be exploited for large scale reflection attacks leading to a dramatic increase of the size of denial of services. Luckily, network providers can already put in place a series of known countermeasures to mitigate these threats, as ENISA underlined also for amplification attacks in April 2013 . The potential of using NTP in attacks is not new: NTP misuse and abuse have been around since the late nineties , nevertheless the possibility to use the monlist vulnerability as an attack vector against specific targets was first publicly underlined in 2010 and early attempts to use this vulnerability can be traced back to 2011 . Unfortunately this specific vulnerability started to be exploited for highly recognizable objectives at the end of 2013, first on gaming sites and recently to target a content delivery network reaching enormous volumes per second. NTP allows synchronizing the time for any services between client and server and this attack exploits a functionality to retrieve a list of IP addresses that queried the server before the request. When addressing this specific request (monlist) using a spoofed victim IP address, the victim receives back the list of up to 600 IP addresses that queried the server before . Due to the large size of incoming packets for a small request packet, the response can generate a denial of service as in the recent attack to a content delivery network where the attacker used 4,529 NTP servers running on 1,298 different networks generating approximately 400Gbps of traffic . As Trusted Introducer reported on 13 January 2014, there are approximately 600,000 vulnerable hosts all over Europe . Later in January Shodan published also a map of possible vulnerable servers 8 9 10 around the world . Fortunately, at the same time, official vulnerability advisories were released and various contributions for mitigations started to appear. It is clear that the trend of amplification and reflection attacks exploiting network core protocols is not going to stop: all UDP protocols that allow source IP spoofed attacks can be exploited for large scale DDoS or DRDoS . This is not 12 13 14 restricted to DNS and NTP but also CharGEN , SNMP , NetBIOS, QOTD and others services that in some case are not even used anymore.

text: Recommendations

text: Reflected / spoofed attack have been around since 1997 but specific DNS and NTP (or other UDP protocols) amplification and reflections attacks have gained momentum only in the last few years. As for other attacks, first of all it is useful to

text:  disable unused services. If this is not possible, configure them with particular attention to the possible attack surface

text: Then, if possible, implement

text:  BCP38 ‘’Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing’’  BCP84 ‘’Ingress Filtering for Multihomed Networks’’

text: to filter traffic and block NTP and also all other source IP spoofed attacks .

text: Page 1

text: Additionally, to prevent and mitigate NTP attacks use also the following resources:  check if your machine is vulnerable on openntpproject.org  configure NTP client on Cisco IOS, Juniper JUNOS or iptables using Team Cymru Secure NTP Template  upgrade ntpd to at least 4.2.7 , if it is not possible check how to block/disable queries on ntp.org

text: ENISA and the security and resilience of the Internet Infrastructure in Europe

text: ENISA will continue to investigate the area of Internet Infrastructure with the aim of providing all stakeholders in European Union Member States with recommendations on how to foster security and resilience. This year ENISA will follow up the 2013 report "Understanding the importance of the Internet Infrastructure in Europe" working with subject matter experts from the Internet operators’ community, Cybersecurity agencies, NRAs and infrastructure security and resilience experts on vulnerabilities of the Internet infrastructure and related topics. For further information on the security and resilience of the Internet Infrastructure in Europe see also ENISA’s website or send an email to resilience@enisa.europa.eu.

text: Flash Note produced by Rossella Mattioli, Security and Resilience of Communication Networks Officer, ENISA

text: ENISA’s Flash Notes are issued by the Agency to draw the attention of the media and other interested parties to emerging issues in cyber security. The material contained in Flash Notes may be reproduced freely, provided the source is acknowledged.

text: References

text: 6 3

text: Page 2

type: vagledning

utgivare: enisa