text: See https://www.enisa.europa.eu/topics/iot-and-smart-infrastructures/smart-homes 8 See https://www.enisa.europa.eu/topics/iot-and-smart-infrastructures/smart-cities 9 See https://www.enisa.europa.eu/topics/critical-information-infrastructures-and-services/smart-grids 10 See https://www.enisa.europa.eu/publications/cyber-security-and-resilience-of-smart-cars 11 See https://www.enisa.europa.eu/publications/securing-smart-airports 12 See https://www.enisa.europa.eu/topics/critical-information-infrastructures-and-services/health 13 See http://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016L1148&from=EN 14 See http://www.eugdpr.org/

text: 16 action plan for Europe , as well as the work of the Alliance for the Internet of Things (AIOTI) and the Staff Working Document on ICT Standardization , among others.

text: See EPRS, Ron Davies, «Industry 4.0», http://www.europarl.europa.eu/RegData/etudes/BRIE/2015/568337/EPRS_BRI(2015)568337_EN.pdf

text: See https://qz.com/228750/the-internet-of-things-may-not-need-an-internet-connection/ 58 See https://www.windriver.com/whitepapers/security-in-the-internet-of-things/wr_security-in-the-internet-of-things.pdf

text: See https://www.enisa.europa.eu/topics/threat-risk-management/threats-and-trends/enisa-threat-landscape/etl2015/enisa-threat-taxonomy-atool-for-structuring-threat-information

text: 3,1 Exploit Kits4,0 APTs 4,1 Malware

text: See http://www.csoonline.com/article/3148806/internet-of-things/the-iot-gateway-for-enterprise-hackers.html 72 See https://securelist.lat/iot-el-da-que-ataqu-mi-propia-casa/72452/

text: See https://www.enisa.europa.eu/publications/info-notes/major-ddos-attacks-involving-iot-devices 75 See http://www.energycollection.us/Companies/ICIT/Rise-Machines.pdf

text: See https://www.govtechworks.com/iot-security-risks-begin-with-supply-chains/

text: 77,78,79,80 There have been several studies on design and development concerns related to IoT security . During the interviews engaged within the context of this report we validated the findings of these studies and in this respect the following issues seem particularly significant in the context of IoT design and development:  No defence-in-depth strategy during the design of the system, such as a secure boot process, isolation of a Trusted Computing Base, limitation of the number of open ports, self-protection, etc.  No security-by-design or privacy-by-design. In some cases, information is exchanged with a third-party, and it should be ensured that not more information than strictly needed is exported outside of the IoT environment.  Lack of communication protection, on internal as well as external interfaces.

identifier: Baseline Security Recommendations for IoT

amnesord: Artificial Intelligence and Next Gen Technologies

title: Baseline Security Recommendations for IoT

text: in the context of Critical Information Infrastructures NOVEMBER 2017 www.enisa.europa.eu European Union Agency For Network And Information Security

text: Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017

text: 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 Europe’s citizens. ENISA works with these groups to develop advice and recommendations on good practice in information security. It assists EU 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 EU 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. Contact For contacting the authors please use resilience@enisa.europa.eu. For media enquiries about this paper, please use press@enisa.europa.eu. Acknowledgements Over the course of this study, we have received valuable input and feedback from: Mirko Ross Digital Worx GmbH Hannes Tschofenig ARM Ltd. Antonio J. Jara HOP Ubiquitous S.L. (HOPU) Carlos Valderrama Geomantis Corporation Limited Alessandro Cosenza Bticino S.p.A. Vyacheslav Zolotnikov Kaspersky Lab Yun Shen Symantec Corporation Sylvie Wuidart STMicroelectronics N.V. Paul Murdock Landis+Gyr AG Caroline Greer Cloudflare, Inc. Marc Rogers Cloudflare, Inc. Julio Hernández Castro University of Kent Jacques Kruse-Brandao NXP Semiconductors N.V. Barbara Pareglio GSM Association (GSMA) Jesus Luna Garcia Robert Bosch GmbH Vangelis Gazis Huawei Technologies Co., Ltd. Wolfgang Klasen Siemens AG Hans Aschauer Siemens AG Cédric Lévy-Bencheton Andrei Robachevsky Internet Society (ISOC) Steve Olshansky Internet Society (ISOC) Gianmarco Baldini EC DG Joint Research Centre (JRC) Michael Glenn Cable Television Laboratories, Inc. (CableLabs) Benedikt Abendroth Microsoft Corporation Aaron Kleiner Microsoft Corporation Mike Edwards International Business Machines Corporation (IBM) Filip Chytrý Avast Software s.r.o. Mahmoud Ghaddar Legrand S.A. Europol/EC3 02 Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017 EC DG CONNECT E4 Finally, we thank the experts of the ENISA IoT Security (IoTSec) Expert Group and all participants to the ENISA validation workshop in The Hague in October 2017 for providing us useful feedback during discussions and interviews. Legal notice Notice must be taken that this publication represents the views and interpretations of the authors and editors, 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. 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. 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. Copyright Notice © European Union Agency for Network and Information Security (ENISA), 2017 Reproduction is authorised provided the source is acknowledged. ISBN: 978-92-9204-236-3, doi: 10.2824/03228 03 Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017

text: Table of Contents

text: Executive Summary 7 Index of tables 9 Index of figures 10 1. Introduction 11 Objectives 11 Scope 12 EU and International Policy context 13 Target audience 15 Methodology 16 Structure 16 2. The IoT paradigm 18 Elements of IoT 19 2.1.1 Things in the Internet of Things 19 2.1.2 Intelligent decision making 19 2.1.3 Sensors and actuators 19 2.1.4 Embedded systems 20 2.1.5 Communications 21 Security considerations 22 Challenge of defining horizontal baseline security measures 23 Architecture 24 Asset taxonomy 26 3. Threats and risk analysis 30 Security incidents 30 Threat taxonomy 31 Examples of IoT cyber security attack scenarios 35 Critical attack scenarios 38 3.4.1 Attack scenario 1: IoT administration system compromise 39 3.4.2 Attack scenario 2: Value manipulation in IoT devices 41 3.4.3 Attack scenario 3: Botnet / Commands injection 43 4. Security measures and good practices 46 Policies 47 04 Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017 4.1.1 Security by design 47 4.1.2 Privacy by design 47 4.1.3 Asset Management 48 4.1.4 Risk and Threat Identification and Assessment 48 Organisational, People and Process measures 48 4.2.1 End-of-life support 48 4.2.2 Proven solutions 48 4.2.3 Management of security vulnerabilities and/or incidents 48 4.2.4 Human Resources Security Training and Awareness 48 4.2.5 Third-Party relationships 48 Technical Measures 49 4.3.1 Hardware security 49 4.3.2 Trust and Integrity Management 49 4.3.3 Strong default security and privacy 49 4.3.4 Data protection and compliance 49 4.3.5 System safety and reliability 50 4.3.6 Secure Software / Firmware updates 50 4.3.7 Authentication 50 4.3.8 Authorisation 50 4.3.9 Access Control - Physical and Environmental security 50 4.3.10 Cryptography 51 4.3.11 Secure and trusted communications 51 4.3.12 Secure Interfaces and network services 51 4.3.13 Secure input and output handling 51 4.3.14 Logging 52 4.3.15 Monitoring and Auditing 52 5. Gaps analysis 53 Gap 1: Fragmentation in existing security approaches and regulations 53 Gap 2: Lack of awareness and knowledge 54 Gap 3: Insecure design and/or development 54 Gap 4: Lack of interoperability across different IoT devices, platforms and frameworks 55 Gap 5: Lack of economic incentives 55 Gap 6: Lack of proper product lifecycle management 55 6. High-level recommendations to improve IoT cybersecurity 57 Recommendations 57 Detailed recommendations 57 6.2.1 Promote harmonization of IoT security initiatives and regulations 57 6.2.2 Raise awareness for the need for IoT cybersecurity 58 6.2.3 Define secure software/hardware development lifecycle guidelines for IoT 58 6.2.4 Achieve consensus for interoperability across the IoT ecosystem 59 6.2.5 Foster economic and administrative incentives for IoT security 59 05 Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017 6.2.6 Establishment of secure IoT product/service lifecycle management 59 6.2.7 Clarify liability among IoT stakeholders 60 Glossary 61 Annex A: Detailed Security measures / Good practices 63 Annex B: Security measures and threats mapping 82 Annex C: Security standards and references reviewed 88 Annex D: Description of indicative IoT security incidents 100 06 Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017

text: Executive Summary

text: The Internet of Things (IoT) is a growing paradigm with technical, social, and economic significance. For ENISA, IoT is an emerging concept comprising a wide ecosystem of interconnected services and devices, such as sensors, consumer products and everyday smart home objects, cars, and industrial and health components. These technologies collect, exchange and process data in order to dynamically adapt to a specific context, transforming the business world and the way we live as a whole. IoT is tightly bound to cyber-physical systems and, in this respect, safety implications are pertinent. Nevertheless, IoT poses very important safety and security challenges that need to be addressed for IoT to reach its full potential. Many security considerations regarding IoT are not necessarily new; they are inherited from the use of networking technologies. However, the characteristics of some IoT implementations present new security challenges, threats and risks that are manifold and evolve rapidly. The protection of IoT deployments depends on the protection of all systems involved (the devices themselves, cloud backend and services, applications, maintenance and diagnostic tools, etc.). Addressing these challenges and ensuring security in IoT products and services is a fundamental priority. One of the main concerns is the impact that the different threats may have since attacks on IoT deployments could dramatically jeopardise people’s security, privacy and safety, while additionally IoT in itself can be used as an attack vector against other critical infrastructures. Also, since IoT can drastically change the ways personal data is collected, analysed, used, and protected, privacy concerns have been raised. These need to be addressed to ensure user trust and confidence in the Internet, connected devices, and related services. However, beyond technical security measures, the adoption of IoT has raised many new legal, policy and regulatory challenges, broad and complex in scope, that remain unanswered, amplifying at the same time some existing issues. The rapid rate of change in IoT technology has outpaced the ability of the associated policy, legal, and regulatory structures to adapt, leaving no clear security framework to follow. This has led most companies and manufacturers to take their own approach when designing IoT devices, causing interoperability issues between devices from different manufacturers, and between IoT devices and legacy systems. For these reasons, ENISA is defining a set of Baseline Security Recommendations for IoT. The aim of this work as reported here is 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. As a result of this work, after taking into consideration all the background research carried out, the views expressed by the experts interviewed, and the good practices and security measures identified, a series of recommendations has been developed, namely:  Promote harmonization of IoT security initiatives and regulations Intended for IoT industry, providers, manufacturers, associations  Raise awareness for the need for IoT cybersecurity Intended for IoT industry, providers, manufacturers, associations, academia, consumer groups, regulators  Define secure software/hardware development lifecycle guidelines for IoT Intended for IoT developers, platform operators, industry, manufacturers 07 Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017  Achieve consensus for interoperability across the IoT ecosystem Intended for IoT industry, providers, manufacturers, associations, regulators  Foster economic and administrative incentives for IoT security Intended for IoT industry, associations, academia, consumer groups, regulators  Establishment of secure IoT product/service lifecycle management Intended for IoT developers, platform operators, industry, manufacturers  Clarify liability among IoT stakeholders Intended for IoT industry, regulators 08 Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017

text: Index of tables

text: Table 1 Indicative listing of communication protocols for IoT 22 Table 2 Asset taxonomy 28 Table 3 Threat taxonomy 35 Table 4 IoT attack scenarios 36 Table 5 Attack 1 – IoT administration system compromise 41 Table 6 Attack 2 – Value manipulation in IoT devices 43 Table 7 Attack 3 – Botnet / Commands injection 45 Table 8 IoT Security Recommendations 57 09 Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017

text: Index of figures

text: Figure 1: Methodology followed in the study 16 Figure 2: IoT pervasive ecosystem 18 Figure 3: Structure of an IoT embedded system 21 Figure 4: IoT High-level reference model 25 Figure 5: Asset taxonomy 26 Figure 6: Asset criticality 28 Figure 7: Indicative timeline of IoT security incidents 30 Figure 8: IoT Threat taxonomy 32 Figure 9: IoT threats impact 33 Figure 10: Threat impact weighted average 33 Figure 11: Attack scenario criticality 39 Figure 12: Attack 1 – IoT administration system compromised 40 Figure 13: Attack 2 – Value manipulation in IoT devices 42 Figure 14: Attack 3 – Botnet / Commands injection 44 Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017

text: 1. Introduction

text: The Internet of Things (IoT) is concept paradigm that has emerged over the last years. Kevin Ashton introduced the concept of IoT back in 1999 . It describes a wide ecosystem where interconnected devices and services collect, exchange and process data in order to adapt dynamically to a context. The Internet of Things is tightly bound to cyber-physical systems and in this respect is an enabler of Smart Infrastructures by enhancing their quality of service provisioning. The IoT is the natural evolution of computing and it brings its own challenges – an immature ecosystem bearing a fragmentation of standards and security concerns in a non-homogeneous IoT market, as at the moment each industry and application is different. Another IoT challenge worth highlighting is its ability to scale globally ; according to Gartner, IoT will involve 8.4 billion connected ‘things’ in use in 2017, up 31% from 2016, and by 2020 the number of connected devices is envisioned to reach 20 billion . Currently there are different solutions available in the market through various manufacturers such as Google, Microsoft, Amazon, Apple or Samsung, among others, many of which use their proprietary cloud service, protocols and operating system . The threats and risks related to the Internet of Things devices, systems and services are manifold, and evolve rapidly. With a great impact on citizens’ safety, security and privacy, the threat landscape concerning the Internet of Things is extremely wide. Hence, it is important to understand what needs to be secured and to develop specific security measures to protect the Internet of Things from cyber threats. Involving billions of intelligent systems and millions of applications, IoT will drive new consumer and business behaviours, which will demand increasingly intelligent solutions. This, in turn, is expected to drive by 2020 almost 3 trillion dollars (circa 2.85 trillion euros) in new business opportunities for the different vendors and 41 4 companies that capitalise on the IoT . Examples of these opportunities include :  New business models: New value streams for customers, with a faster response.  Diversification of revenue streams: Monetising added services on top of traditional lines of business.  Real-time information: Capturing data about products and processes more swiftly, improving market agility and allowing prompt decision making.  Global visibility: Making tracking easier from one end of a supply chain to the other. Objectives The goal of this report is to elaborate baseline cybersecurity recommendations for IoT with a focus on Critical Information Infrastructures, which encompass facilities, networks, services and physical and information technology equipment. These infrastructures are considered critical because their destruction or disruption could bring about major consequences for the health, safety and economic wellbeing of citizens, for the 5,6 efficient functioning of State institutions and Public Administrations , and for the asset owners who make use of IoT to provide their services.

text: 1 See http://www.rfidjournal.com/articles/view?4986 2 See https://www.emc.com/leadership/digital-universe/2014iview/internet-of-things.htm 3 See https://hacks.mozilla.org/2017/06/building-the-web-of-things/ 4 See https://www.emc.com/leadership/digital-universe/2014iview/internet-of-things.htm 5 See https://ec.europa.eu/home-affairs/what-we-do/policies/crisis-and-terrorism/critical-infrastructure_en 6 See https://www.enisa.europa.eu/topics/critical-information-infrastructures-and-services

text: Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017 In this respect, the baseline security measures for IoT put forward in this report can serve as a springboard for further related efforts towards a harmonised EU approach, paving the way for a tacit adoption of the measures, and as criteria for other initiatives such as labelling or certification. A major challenge in defining baseline security measures for IoT is the entailed complexity that is brought by the diversity of application areas for IoT. Striking a balance between the particularities of each domain is essential and accordingly it is important to consider the differences in apportioning risk to distinct environments. Accordingly, this report builds on the expertise and insight gained by previous work by ENISA, covering a series of vertical application areas of IoT namely:  Smart Homes  Smart Cities and Intelligent Public Transport  Smart Grids  Smart Cars  Smart Airports  eHealth and Smart Hospitals This report aims to cover the threat model of the Internet of Things in the context of Critical Information Infrastructures (CII), as well as to detail available security measures to counter the identified threats. This report also provides a series of recommendations to shape future efforts and initiatives in the direction of a holistic approach to secure the Internet of Things. Scope ENISA defines the Internet of Things (IoT) as a cyber-physical ecosystem of interconnected sensors and actuators, which enable decision making. Information lies at the heart of IoT, feeding into a continuous cycle of sensing, decision making, and actions. IoT is tightly bound to cyber-physical systems and in this respect is an enabler of Smart Infrastructures, e.g. Industry 4.0, smart grid, smart transport, by enabling services of higher quality and facilitating the provision of advanced functionalities. ENISA identified and analysed existing IoT security practices, security guidelines, relevant industry standards and research initiatives in the area of IoT security for Critical Information Infrastructures (e.g. Industry 4.0, Machine-to-Machine (M2M) communications, IoT updatability). Having reviewed and thoroughly analysed existing work and ongoing activities, ENISA compared these practices and standards and developed baseline security measures to be adopted by relevant stakeholders. ENISA focused, among other topics, on IoT resilience and communication, on the interoperability with proprietary systems, and on the reliability of IoT. Special emphasis was given to the privacy issues of such smart infrastructure and services. In this endeavour, ENISA additionally took into account existing European Union (EU) policies and regulatory initiatives such as the Directive on security of network and information 13 14 systems (NIS Directive) , The EU General Data Protection Regulation (GDPR) , the Internet of Things - An Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017 In 2017, ENISA launched the IoT Security Experts Group (IoTSEC) . The ENISA IoTSEC group is an information exchange platform that brings together experts to ensure the security and resilience of the entire Internet of Things ecosystem. Experts of the IoTSEC group have background expertise in one or several of the following:  Internet of Things with a focus on cyber security;  Suppliers and developers of Internet of Things hardware and/or software with a focus on cyber security;  Associations and non-profit organisations involved in Internet of Things security;  Regulation bodies, academia, standardisation bodies and policy makers. The first step of the process followed by ENISA in order to validate the results of the report was to carry out a series of interviews with the different members of the IoTSEC Experts Group, where we gathered their input, obtaining new information and validating information found during the desktop research. A total of 26 experts were interviewed, covering industry, policy, academia and research organisations from 9 EU member states and from the United States of America. After synthesising all findings into this report, a release candidate version was sent to the experts that compose the IoTSEC Group for a first round of comments. Finally, during the first workshop meeting of the ENISA IoT Security Experts Group that took place in The Hague, Netherlands, on 20th of October 2017, the findings of the report were discussed and the experts shaped the final recommendations in order to reflect the needs of the IoT security community in Europe. EU and International Policy context In the last years, the European Commission has been working to facilitate the embracement of the IoT in Europe, and to unleash its full potential, by adopting a set of supporting policy actions and launching a series of relevant initiatives . In March 2015, the European Commission launched the Alliance for Internet of Things Innovation (AIOTI) , with the intention of creating an innovative and industry-driven European IoT ecosystem. The AIOTI has come to be the largest European IoT Association to date, emphasising the European Commission’s ambition to work closely with all IoT stakeholders on the establishment of a competitive IoT market and new business models for the benefit of the European citizens and businesses. The Digital Single Market (DSM) Strategy , adopted two months later in May 2015, underlines the need to avoid fragmentation and to foster interoperability for IoT to reach its potential, leading Europe a step further in terms of IoT development. In order to meet the DSM needs and to inform about its upcoming policy, in April 2016 the European Commission specified the EU’s IoT vision in the document ‘Advancing the Internet 22 23 of Things in Europe’ , as part of the ‘Digitising European Industry’ (DEI) initiative .

text: 15 See http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=COM:2009:0278:FIN:EN:PDF 16 See https://ec.europa.eu/digital-single-market/en/news/alliance-internet-things-innovation-aioti-defines-its-long-term-strategy 17 See https://ec.europa.eu/digital-single-market/en/news/communication-ict-standardisation-priorities-digital-single-market 18 See https://resilience.enisa.europa.eu/iot-security-experts-group-1 19 See https://ec.europa.eu/digital-single-market/en/internet-of-things 20 See https://ec.europa.eu/digital-single-market/en/alliance-internet-things-innovation-aioti 21 See https://ec.europa.eu/commission/priorities/digital-single-market/ 22 See https://ec.europa.eu/digital-single-market/en/news/staff-working-document-advancing-internet-things-europe 23 See https://ec.europa.eu/digital-single-market/en/policies/digitising-european-industry

text: Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017 This vision is based on three different pillars:  A thriving IoT ecosystem,  A human centred IoT approach,  A single market for IoT. The achievement of a single market for the IoT will potentially face issues linked to the capacity to handle a vast number and diversity of connected devices and the ability to identify them unequivocally and universally, so it is important to foster an open system for object identification and authentication, as well as an interoperable IoT numbering space that transcends geographical limits. Some aspects of numbering were already addressed in the 2016 review of the EU telecom rules . The Commission, in their ICT Standardisation roadmap for the Digital Single Market , identified five priority areas that aim to guarantee a fresh approach to standards, and IoT is identified as one of these five priorities. These areas should increase competitiveness and help European innovations better access the global market. The other priorities are 5G communication, cybersecurity, cloud and Big Data. In the context of promoting a European single market for IoT, in January 2017 the ‘European data economy’ initiative was presented . It proposes policy and legal solutions concerning the free flow of data across national borders in the EU, and liability issues decisive to enhance legal certainty around IoT products and services. In addition to all these initiatives, the EU has arranged specific IoT objectives in the Horizon 2020 research and innovation programme . The midterm review of the Digital Single Market makes numerous references to the Internet of Things, with liability and cyber security being the main areas of focus . Moreover,

text: Article 29

text: Data Protection Working Party Committee’s “Opinion 8/2014 on the on Recent Developments on the Internet of Things” identifies the main data protection risks that lie within the ecosystem of the IoT before providing guidance on how the EU legal framework should be applied in this context . The most recent action taken by the EU was on September 2017, when the new “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 30,31 (“Cybersecurity Act”)” was published . On the same date, the European Commission published the “Joint Communication To The European Parliament And The Council Resilience, Deterrence and Defence: Building strong cybersecurity for the EU” , which describes the overall cybersecurity strategy of the EU. The goal is to build greater EU resilience to cyber-attacks, improving detection mechanisms and strengthening international cooperation, and to do so, the document provides a series of measures, with some of them specifically oriented to IoT, such as the encouragement of “security by design” through the whole lifecycle of the devices that make up the Internet of Things. With this measure, schemes under this framework would indicate that the products are built using

text: 24 See https://ec.europa.eu/digital-single-market/en/connectivity-european-gigabit-society 25 See https://ec.europa.eu/digital-single-market/en/news/communication-ict-standardisation-priorities-digital-single-market 26 See https://ec.europa.eu/digital-single-market/en/building-european-data-economy 27 See https://ec.europa.eu/digital-single-market/en/research-innovation-iot 28 See https://ec.europa.eu/digital-single-market/en/news/digital-single-market-commission-calls-swift-adoption-key-proposals-and-maps-outchallenges 29 See http://ec.europa.eu/justice/data-protection/article-29/documentation/opinion-recommendation/files/2014/wp223_en.pdf 30 See http://eur-lex.europa.eu/resource.html?uri=cellar:1985b4b4-985e-11e7-b92d-01aa75ed71a1.0001.02/DOC_1&format=PDF 31 See http://eur-lex.europa.eu/resource.html?uri=cellar:1985b4b4-985e-11e7-b92d-01aa75ed71a1.0001.02/DOC_2&format=PDF 32 See http://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=JOIN:2017:450:FIN&from=EN

text: Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017 state-of-the-art secure development methods, that they have undergone adequate security testing, and that the vendors have committed to update their software in the event of newly discovered vulnerabilities or threats. Moving from the EU to the US, it is worth highlighting the “Internet of Things Cybersecurity Improvement Act of 2017” , introduced on the 1st of August of 2017 by four U.S. senators, which was developed in response to a series of IoT-related cyber-attacks that took place in 2016 . This improvement act establishes minimum cybersecurity requirements for connected devices purchased by the U.S. Government, including :  Requiring vendors to ensure their devices are patchable, rely on industry standard protocols, do not use hard-coded passwords, and do not contain any known security vulnerabilities;  Requiring vendors selling IoT devices are “to provide written certification that the device does not contain, at the time of submitting the proposal, any hardware, software, or firmware component with any known security vulnerabilities or defects” . If a vendor identifies vulnerabilities, it must disclose them and patch them in a timely manner ;  Requiring each executive agency to inventory all Internet-connected devices in use by the agency;  Along with NIST, specifying particular measures, e.g. network segmentation, for agencies to employ them;  Directing the Department of Homeland Security’s (DHS) National Protection and Programs Directorate (NPPD) to develop coordinated disclosure guidelines, allowing researchers to uncover vulnerabilities in and share them with the vendors; and  Requiring an effectiveness report, with recommendations for updates, to be submitted to Congress after 5 years. Target audience This report provides a set of specific baseline security measures and recommendations that can be applied to protect IoT systems and environments. The primary target audience of the report are organisations that want to adopt IoT or are already adopting IoT solutions as well as the manufacturers and operators that provide IoT products, solutions and services. This report is also aimed at the personnel responsible for IT and/or innovation activities in their organisations, including the following profiles:  IoT experts, software developers and manufacturers  Information security experts  IT/Security solutions architects  Chief Information Security Officers (CISOs)  Critical Information Infrastructure Protection (CIIP) experts It is noteworthy that the recommendations of the report can prove to be beneficial to support policy making initiatives in regard to IoT security and hence are also aimed at corresponding regulators.

text: 33 See https://www.congress.gov/bill/115th-congress/senate-bill/1691/text 34 See https://krebsonsecurity.com/tag/iot-cybersecurity-improvement-act-of-2017/ 35 See https://www.helpnetsecurity.com/2017/08/02/iot-security-legislation/ 36 See https://dzone.com/articles/internet-of-things-cybersecurity-improvement-act-o 37 See https://www.wired.com/beyond-the-beyond/2017/08/spime-watch-fact-sheet-internet-things-cybersecurity-improvement-act-2017/

text: Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017 Methodology This study was carried out using a five-step methodology (shown in Figure 1) which begins with the scope definition, the initial information gathering from official sources and experts in the field and ends in the development of a report summarizing the findings and the recommendations to the target audience.

text: Task 2 Task 4 •Collection of the •SScope definition and •Desktop • • Analysis and Report write-up stakeholders' and experts' identification of experts research development and validation point of view Task 1 Task 3 Task 5

text: Figure 1: Methodology followed in the study 1. Scope definition and identification of experts: The first step was to establish the report’s scope and perimeter and then to identify the IoT experts, so as to gather their input and knowledge in relation to the objectives of this report. 2. Desktop research: In parallel with the expert identification, an investigation was carried out to identify existing publications and information on the topics related to the objectives of the report, which will serve as support for the analysis of the threats and for the development of the security measures. 3. Collection of stakeholders’ and experts’ point of view: A series of interviews were conducted with the experts from the IoTSEC Experts Group, using an internally developed questionnaire to guide them and to ensure that we obtained the most relevant input. 4. Analysis and development: The results from the desktop research and the interviews were analysed and contrasted to align them with the objectives of the report, developing the assets and threats taxonomies and identifying the attack scenarios, as well as identifying the baseline security measures, the gaps and the recommendations to address them. 5. Report write-up and validation: The last step was to synthesise all the findings from the desktop research and the interviews with the experts, shaping this report, which was finally validated in the workshop meeting with the IoT experts that have collaborated in the study. Structure The rest of the report is structured as follows:  Chapter 1: Introduction to the report and definition of the objective and the methodology followed to achieve it.  Chapter 2: Definition and documentation about IoT key elements and environments.  Chapter 3: Analysis of the main threats, vulnerabilities, risks and the development of the main attack scenarios.  Chapter 4: Development, mapping and categorisation of the main security measures that have been identified and that apply in the scope of the report.  Chapter 5: Gaps and future challenges applicable to the scope of the project. Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017  Chapter 6: Security recommendations based on the security measures developed and the gaps and challenges identified in the previous chapters. Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017

text: 2. The IoT paradigm

text: ENISA defines IoT as “a cyber-physical ecosystem of interconnected sensors and actuators, which enable intelligent decision making”. Stemming from the definition is the fact that information lies at the heart of IoT, feeding into a continuous cycle of sensing, decision making, and actions. Figure 2: IoT pervasive ecosystem Figure 2 illustrates the pervasive nature of IoT in that it is at the core of a plethora of both critical and noncritical infrastructures. IoT is pertinent to almost all aspects of daily life, affecting commercial applications, the industrialisation, or the private sphere, to name a few. Inherently, IoT builds on embedding “intelligence” in everyday objects, thus increasing the usefulness of what used to be common “things”, and therefore facilitating all aspects of daily life by providing a greater automation and control in sectors such as industry, energy, transport, health, retail, etc. The majority of the sectors associated with IoT are critical, and any incident affecting them can thus severely affect society as a whole. Industry 4.0 and Industrial Internet of Things (IIoT) are frequently and rightfully associated with IoT focusing 23 38 on digitising industries . Industry 4.0 is the term coined to refer to the world’s fourth industrial revolution . It is defined as the brisk transformation in the design, manufacture, operation and service of manufacturing systems and products, where digital technology and the Internet merge together with the conventional industry, achieving digitally connected manufacturing operations with a highly integrated value chain . In this study, we focus on the more generic concept of IoT. This chapter will provide a brief insight into the IoT elements and architecture, including the different security considerations to be taken into account. Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017 Elements of IoT The following sections provide an overview of the different elements that shape the IoT ecosystem, namely the Things in the IoT, intelligent decision making, sensors and actuators, communications and embedded systems. A detailed IoT asset taxonomy can be found later in chapter 2.5. 2.1.1 Things in the Internet of Things In IoT environments, a thing is a physical or virtual object capable of being identified and integrated into communication networks. It is imperative for things to have the capability of communication – exchanging data over a network between them and/or with the cloud backend services. Additionally, things may have other optional features, such as sensing and capturing data, actuating, storing and processing data, executing native or cloud-based applications, machine learning, etc . The set of ‘things’ that compose an IoT ecosystem can be managed by intelligent systems, which are able to autonomously connect to things for monitoring and controlling them. Moreover, these intelligent systems can retrieve data from a thing or a set of things and process that data, obtaining useful information in order to make an intelligent decision . 2.1.2 Intelligent decision making The number of devices connected to ‘intelligent systems’ that can store, process, analyse and share data is sharply increasing. This will result in billions of ‘things’ and machines connected to networks and producing even more data . Hence, there is a need to deploy data analytics and smart data management techniques in order to draw meaningful insight from the colossal volume of data being generated . Moreover, IoT encompasses the notion of actuating, for which decision making is necessary. Intelligent decision-making depends first and foremost on the information available to make the decisions. These decisions can be as simple as a threshold-crossing mechanism, or as advanced as machine learning or deep learning systems . The output of these decisions will eventually lead to actions and may feed new information into the ecosystem. The information used to make intelligent decisions can be either analysed locally, since some ‘things’ can process the data they gather themselves, or delegated to another element of the IoT ecosystem, such as the cloud backend service, the aggregator/gateway, another ‘thing’, etc. This whole process supports several aspects, such as context awareness and adaptation, autonomy, and self-optimisation/configuration/healing/protection, to name a few. 2.1.3 Sensors and actuators Sensors are one of the key building blocks of IoT, since they are an integral element that allows to monitor the environment and the context on which IoT systems operate. They can be as small as millimetres in size, making them easy to embed in physical objects – from roadways to pacemakers . On the physical level, sensors can measure defined physical, chemical or biological indicators, and on the digital level, they collect information about the network and applications. They then generate associated quantitative data, which can be processed in real-time, or stored for later retrieval, and that can be received

text: 39 ITU-T Y.2060, «Overview of the Internet of things». See https://www.itu.int/rec/T-REC-Y.2060-201206-I 40 European Commission, «Definition of a Research and Innovation Policy Leveraging Cloud Computing and IoT Combination». See https://ec.europa.eu/digital-single-market/en/news/definition-research-and-innovation-policy-leveraging-cloud-computing-and-iot-combination 41 See http://www.gartner.com/newsroom/id/3598917 42 See https://www.forbes.com/sites/mikekavis/2014/09/04/making-sense-of-iot-data-with-machine-learning-technologies/ 43 McKinsey&Company, «The Internet of Things». See http://www.mckinsey.com/industries/high-tech/our-insights/the-internet-of-things

text: Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017 hundreds of kilometres away . Some examples of sensors are accelerometers, temperature sensors, pressure sensors, light sensors and acoustic sensors, among others. Even if they are left unattended in some cases (e.g. roadways), sensors have become essential in a large number of industries, gathering data for the network and applications to dynamically adapt to optimal processes at any moment . An actuator can be considered as the entity responsible for moving or controlling a system or mechanism. In simple terms, an actuator operates in the reverse direction of a sensor. It takes an electrical input and turns it into physical action. Taking the example of smart lamps and smart thermostats, their actuators can make use of the signal coming from a light sensor to regulate brightness, and of the signal coming from a temperature sensor to regulate temperature, respectively. Actuators are also commonly used in manufacturing and assembly processes, where motors and solenoids are the primary examples of actuators – for example, valves are a type of actuator, used to control a hydraulic system . To summarise, the functions of input devices are performed by sensors that gather information about their environment and its context, which will be subsequently processed. In contrast, actuators serve as output units – they act based on the processed information, executing decisions. It should be noted that, in most IoT deployments, sensors and actuators are not only found standalone, but also integrated into embedded systems. 2.1.4 Embedded systems Sensors and actuators are the fundamental elements of IoT. They may be connected to the cloud backend through gateways to have the data coming from the sensors processed, in order to make a decision. Instead of only having sensor and/or actuator networks, IoT devices can also be found as embedded systems, which include embedded sensors and/or actuators, as well as network capabilities to connect directly to a LAN or to the cloud, a memory footprint and the ability to run software. Additionally, IoT embedded systems are based on a processing unit that enables them to process data on their own. Some examples of devices that contain embedded systems comprise medical implants, wearables such as smart watches, connected lights, smart thermostats, etc. Figure 3 illustrates the structure of an embedded IoT system.

text: 44 IEEE, «Towards a definition of the Internet of Things (IoT)». See http://iot.ieee.org/images/files/pdf/IEEE_IoT_Towards_Definition_Internet_of_Things_Revision1_27MAY15.pdf 45 Ammar Rayes, Samer Salam, «The Things in IoT: Sensors and Actuators». See https://link.springer.com/chapter/10.1007/978-3-319-44860-2_3

text: Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017 Figure 3: Structure of an IoT embedded system 2.1.5 Communications Communication requirements vary widely among the different types of IoT networks, depending on their purpose and resource constraints . The selection of protocols to be used in a particular deployment of IoT ecosystems depends on the requirements of its use-case. The combination of different protocols within IoT ecosystems is a common practice, using gateways to ensure interoperability. IoT communication systems rely on the ability to both transmit and receive information units in a structured manner, with services located either nearby or in a distant location, using different but interoperable kinds of network types. These networks have different set of properties such as QoS, resilience, security and management . The communication protocols within IoT ecosystems can be either wireless or wireline-based. There exists a plethora of wireless communication protocols, including short-range radio protocols such as ZigBee , 49 50 51 Bluetooth/Bluetooth Low Energy (BLE) , Wi-Fi/Wi-Fi HaLow , Near Field Communication (NFC) or Radio 52 53 Frequency Identification (RFID) ; mobile networks and longer-range radio protocols such as LoRaWAN , 54 55 56 SigFox NarrowBand-IoT (NB-IoT) , or LTE-M . Each of them is defined in its own standard, for example ZigBee and ZigBee 3.0 are based on IEEE 802.15.4. Wired communication protocols and links, such as Ethernet, USB, SPI, MIPI and I2C, among others, also provide access to the devices. Moreover, it is worth highlighting that IoT communications also support non-IP based protocols, such as SMS, LiDar, Radar, etc.

text: 46 Tara Salman, «Networking Protocols and Standards for Internet of Things». See https://www.cse.wustl.edu/~jain/cse570-15/ftp/iot_prot.pdf 47 ISO/IEC, «ISO/IEC CD 30141:20160910(E) - Internet of Things Reference Architecture (IoT RA)». See https://www.w3.org/WoT/IG/wiki/images/9/9a/10N0536_CD_text_of_ISO_IEC_30141.pdf 48 See http://www.zigbee.org/zigbee-for-developers/network-specifications/ 49 See https://www.bluetooth.com/what-is-bluetooth-technology/how-it-works/le-p2p 50 See http://www.wi-fi.org/news-events/newsroom/wi-fi-alliance-introduces-low-power-long-range-wi-fi-halow 51 See http://nfc-forum.org/nfc-and-the-internet-of-things/ 52 See http://www.rfidjournal.com/articles/view?392 53 See https://www.lora-alliance.org/technology 54 See https://www.sigfox.com/ 55 See https://www.gsma.com/iot/narrow-band-internet-of-things-nb-iot/ 56 See https://www.gsma.com/iot/long-term-evolution-machine-type-communication-lte-mtc-cat-m1/

text: Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017 Wireless technologies have different characteristics, such as a specific signal range, bandwidth, etc. and can be classified as Wireless Personal Area Networks (WPAN), Wireless Local Area Networks (WLAN) or Wireless Wide Area Networks (WWAN). In ENISA’s Smart Homes study , the different kinds of networks were also listed. Nevertheless, given the context of this study, a more generic/horizontal approach has been followed, thus remaining consistent with the Smart Homes study. Table 1 depicts an indicative listing of different protocols grouped by communication layer. The datalink layer handles the connection between IoT devices across a physical link, either wired or wireless, for example between sensors or between a sensor and the gateway that connects a set of sensors to the Internet. The network layer is divided into the routing layer, which handles the packet transfer from the source to the destination, and into the encapsulation layer, which builds the packets. The session layer defines the protocols enabling messaging capabilities among the elements of the IoT communication subsystem . SESSION AMQP, CoAP, DDS, MQTT, XMPP ENCAPSULATION 6LowPAN, Thread NETWORK ROUTING CARP, RPL DATALINK Bluetooth / BLE, Wi-Fi / Wi-Fi HaLow, LoRaWAN, Neul, SigFox, Z-Wave, ZigBee, USB Table 1: Indicative listing of communication protocols for IoT As stated before, IoT ‘things’ need to both transmit and receive data, yet they do not necessarily need an Internet connection to do so, only the ability to pass the data they collect/receive on to other ‘things’ capable of processing that information and/or sending it over an Internet connection. Therefore, it is possible for an IoT ecosystem made up of multiple ‘things’ to operate without any of them being capable of connecting to the Internet . The use of the word ‘Internet’ in the term ‘Internet of Things’ should simply be seen as a generalisation, implying the notion of connectivity. It should not be interpreted in a stricter, technical sense, whereby an Internet connection or the IP protocol stack would be a requirement of the IoT ecosystem. Security considerations As we become increasingly reliant on intelligent, interconnected devices in every aspect of our lives, the billions of “things” can be the target of intrusions and interferences that could dramatically jeopardise personal privacy and threaten public safety . Therefore, security is one of the main concerns regarding IoT, which needs to be addressed along with the paramount need for safety, since both matters are tightly intertwined with the physical world. Another important aspect involves administration of IoT devices, namely who is going to be responsible for this especially considering the inherent complexity and heterogeneity of the IoT ecosystem, as well as taking into account scalability concerns. The following are generic issues identified by this study that hinder the consolidation of secure IoT ecosystems:  Very large attack surface: The threats and risks related to IoT are manifold and evolve rapidly. Considering their impact on citizens’ health, safety and privacy (data collection and processing may be unclear to the users, since IoT is heavily based on the gathering, exchange and processing of large amounts of data from a variety of sources, sometimes including sensitive data), the threat landscape concerning IoT is extremely wide. Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017  Limited device resources: Applying conventional security practices in IoT could require a substantial reengineering due to technical constraints. The majority of IoT devices have limited capabilities, e.g. processing, memory and power, and therefore advanced security controls cannot be effectively applied.  Complex ecosystem: Security concerns are exacerbated since IoT should not be seen as a collection of independent devices, but rather as a rich, diverse and wide ecosystem involving aspects such as devices, communications, interfaces, and people.  Fragmentation of standards and regulations: The fragmented and slow adoption of standards and regulations to guide the adoption of IoT security measures and good practices, as well as the continuous emergence of novel technologies, further complicate relevant concerns.  Widespread deployment: Apart from commercial applications of IoT, recent trends have seen Critical Infrastructures (CIs) migrating toward Smart ones by employing IoT on top of legacy infrastructures.  Security integration: This is a very challenging task, due to the presence of possibly contradicting viewpoints and requirements from all involved stakeholders. For example, different IoT devices and systems may be based on different authentication solutions, which must be integrated and made interoperable.  Safety aspects: They are very relevant in the IoT context because of the presence of actuators, which act on the physical world. Security threats can become safety threats as, for instance, the recent cybersecurity attacks on connected vehicles have demonstrated .  Low cost: The wide penetration of IoT and the advanced functionalities it offers in several critical sectors denotes the potential for significant cost savings by exploiting features such as data flows, advanced monitoring, and integration to name a few. Conversely, it is often the case that the low cost that is usually associated with IoT devices and systems will have implications in terms of security. Manufacturers might be inclined to limit security features to ensure a low cost and thus product security might not be able to protect against certain types of IoT attacks.  Lack of expertise: This is a rather novel domain and therefore there is a lack of people with the suitable skillset and expertise in IoT cybersecurity.  Security updates: Applying security updates to IoT is extremely challenging, since the particularity of the user interfaces available to users does not allow traditional update mechanisms. Securing of those mechanisms is in itself a daunting task, especially considering Over-The-Air updates.  Insecure programming: Since the “time to market” pressure for IoT products is higher than in other domains, this imposes constraints on the available efforts to develop security and privacy by design. For this reason, and sometimes also due to budget issues, companies developing IoT products generally place more emphasis on functionality and usability than on security.  Unclear liabilities: The lack of a clear assignment of liabilities might lead to ambiguities and conflicts in case of a security incident, especially considering the large and complex supply chain involved in IoT. Moreover, the question of how to manage security if one single component were shared by several parties remains unanswered. Enforcing liability is another major issue. Challenge of defining horizontal baseline security measures ENISA together with the vast majority of the experts interviewed agree on the complexity of studying IoT security in a horizontal way, due to the security measures and the impact of the threats being determined by the criticality of the different assets, which differs depending on the use case, the application use and the use scenario. For each IoT environment it is necessary to carry out a risk assessment to go through the threats that can affect the different assets, define the plausible attack scenarios, and put them in the context of the IoT service defined, working out which hazards are critical or not and which ones can be mitigated. These Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017 reasons highlight the intricacy involved in approaching the IoT in a horizontal way, rather than tackling a 59 10 11 12 7 specific IoT vertical such as Smart Cars , Smart Airports , Smart Hospitals , Smart Homes , Intelligent 60 61 Public Transport , ICS/SCADA , etc. Nonetheless, this report considers the horizontal aspects of IoT as seen across vertical sectors and thus aims to satisfy the paramount need to define baseline security measures for IoT across Critical Information Infrastructures. In this respect, this report complements the aforementioned previous efforts of ENISA in the vertical sectors and thus promotes a holistic approach towards IoT security. Architecture Since IoT solutions are developed with specific technologies and focus on specific applications, they lack standardisation, which results in fragmented and heterogeneous architectures. ENISA studied and reviewed several existing IoT architectures and based on them, put forward an architecture that encompasses key elements of those architectures, promoting a significant degree of interoperability across different assets, platforms environments, etc., with the ambition of laying down a common architectural basis for IoT in a horizontal. The main IoT architectures studied are:  AIOTI High Level Architecture functional model  FP7-ICT – IoT-A Architectural reference model  NIST Network of Things (NoT)  ITU-T IoT reference model  ISO/IEC CD 30141 Internet of Things Reference Architecture (IoT RA)  ISACA Conceptual IoT Architecture  oneM2M Architecture Model  IEEE P2413 - Standard for an Architectural Framework Having analysed the aforementioned architectures, we abstracted and extrapolated the fundamental elements into a consolidated high-level IoT reference model, which encompasses the key elements of these architectures. The objective was to utilise this high-level reference model (Figure 4) in order to define the assets for IoT security and to assist us in consistently applying our methodology in identifying threats and attacks. The following diagram depicts this high-level reference model.

text: 59 See https://www.enisa.europa.eu/topics/iot-and-smart-infrastructures 60 See https://www.enisa.europa.eu/publications/good-practices-recommendations 61 See https://www.enisa.europa.eu/publications/ics-scada-dependencies 62 See https://aioti-space.org/wp-content/uploads/2017/03/AIOTI-WG3-IoT-High-Level-Architecture-Release_2_1.pdf 63 See http://www.meet-iot.eu/deliverables-IOTA/D1_5.pdf 64 See http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-183.pdf 65 See https://www.w3.org/WoT/IG/wiki/images/9/9a/10N0536_CD_text_of_ISO_IEC_30141.pdf 66 See https://www.isaca.org/Journal/archives/2017/Volume-3/Pages/default.aspx 67 See http://www.onem2m.org/images/files/deliverables/Release2/TS-0001-%20Functional_Architecture-V2_10_0.pdf 68 See https://standards.ieee.org/develop/project/2413.html

text: Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017 Figure 4: IoT High-level reference model The different elements that compose the IoT high-level reference model are illustrated in Figure 4. It should be noted that we do not aspire to set forth a novel IoT architecture or reference model. Conversely, by analysing existing such efforts we aim at abstracting their fundamental elements in order to coherently and systematically identify the assets to be protected. Moreover, the horizontal nature of security should be underlined in the context of the IoT ecosystem. It applies to all the different elements of the reference model – not only the devices that need to be secured logically and physically, but also the communications, the network elements, the stored information, the cloud platform, etc. With no intention of being exhaustive, there are several security considerations to take into account, such as for example authentication, availability, resilience and authorisation mechanisms, or the use of encryption to protect the confidentiality of data, both at rest and in transit. Figure 4 indicatively lists some of the security mechanisms that can be considered, whereas it should also be noted that privacy has an equally important place and should be also considered across the IoT ecosystem. Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017 Asset taxonomy Tackling cyber security starts from asset identification and decomposition. This section provides an overview of the key asset groups and assets to be protected in an IoT ecosystem. Since we are approaching IoT in a horizontal way, the level of protection for a given asset will vary depending on the use case, the application used and the use scenario of said IoT ecosystem. The different IoT assets have been divided into the key asset groups defined. This asset taxonomy is depicted in Figure 5, and Table 2 details and elaborates on the different assets. It should be noted that the lowest level of the taxonomy is indicative and not exhaustive. For instance, not all sensor types are listed, just some representative ones. This also applies to the networks, the protocols, etc. Figure 5: Asset taxonomy Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017 ASSET GROUP ASSETS DESCRIPTION The different physical components (except sensors and actuators) from which the IoT Hardware devices can be built. These include microcontrollers, microprocessors, the physical ports of the device, the motherboard, etc. Software comprises the IoT device’s OS, its firmware and the programs and applications Software installed/running. IoT Devices These are the subsystems whose purpose is to detect and/or measure events in its Sensors environment and send the information to other electronics in order to be processed. There are sensors for a lot of purposes, such as to measure temperature, motion, etc. These are IoT device’s output units, which execute decisions based on previously Actuators processed information. These are devices whose purpose is to serve as an interface or as an aggregator between Devices to interface other IoT devices of a given IoT ecosystem. Moreover, devices used by users to interface with Things and interact with IoT devices. Other IoT Devices to manage Ecosystem These are devices specially designed to manage other IoT devices, networks etc. Things Devices They are based on a processing unit that enables them to process data on their own. Embedded systems They include embedded sensors and/or actuators, network capabilities to connect directly to the cloud, a memory footprint and the ability to run software. They allow the different nodes of an IoT ecosystem to exchange data and information Networks with each other, via a data link. There are different kinds of networks according to their spatial coverage, which include (W)LANs, (W)PANs, PANs and (W)WANs, among others. Communications They define the set of rules on how communication between two or more IoT devices must be performed through a given channel. There are many communication protocols, Protocols which can be either wireless or wireline-based. Examples of IoT communication protocols are ZigBee, MQTT, CoAP, BLE, etc. They are the networking components that forward data packets between the different Routers networks of the IoT ecosystem. These are the network nodes used for interfacing with another network from the IoT Gateways environment that uses different protocols. Gateways may provide protocol translators, fault isolators, etc., to provide system interoperability. Infrastructure It supplies electric power to an IoT device and to its internal components. The power Power supply source can be external and wired or a battery integrated in the device itself. This group comprises the assets specifically focused on the security of the IoT devices, networks and information. Most prominently, these include firewalls, Web Application Security assets Firewalls (WAF), CASBs for protecting the cloud, IDSs, IPSs and authentication/authorisation systems. These are services within the World Wide Web, which provide a web-based interface to Web-based services web users or to web-connected applications. This means web technologies can be used Platform & in IoT for Human-to-Machine (H2M) communications and for M2M communications. Backend Cloud infrastructure In IoT, the cloud backend can be used to aggregate and process data from dispersed and services devices, and it also provides computing capabilities, storage, applications, services, etc. This refers to algorithms and services to process collected data and transform it into a Data mining defined structure for further use, using big data technologies for discovering patterns in very large data sets. Decision making Services facilitating the processing of gathered data in order to obtain useful Data processing and information, which can be used to apply rules and logic, to make decisions and to computing automate processes. Machine learning can be employed to learn from the use of information available over time. Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017 Once the data has been collected and processed, the resulting information can be Data analytics and analysed and visualised in order to identify new patterns, improve operational visualisation efficiency, etc. The management of the IoT ecosystem devices and networks includes the software Applications & Device and network updates of the OS, firmware and applications. It also encompasses the tracking and Services management monitoring of the devices and networks, collecting and storing logs that can later be used for diagnostics. The contextualisation of the IoT ecosystem devices and networks, so as to understand Device usage the current status, usage patterns, performance, etc. At rest Information stored in a database in the cloud backend or in the devices themselves. Information sent or exchanged through the network between two or more IoT Information In transit elements. In use Information used by an application, service or IoT element in general. Table 2: Asset taxonomy Figure 6 provides a view of the criticality of the main assets described in the asset taxonomy, based on the responses received by the subject matter experts in the interviews. These interviews involved a structured questionnaire where one of the questions the experts were asked was to evaluate the main IoT assets according to their criticality. The experts could classify the assets as not important, of low importance, of medium importance, of high importance and of crucial importance. It is worth putting again special emphasis on the complexity of defining the criticality of a given asset in a horizontal way rather than considering a specific vertical use case. Abstracting from this fact is very challenging, but that is the goal of this report. Sensors 78% Device & network management 72% Communication protocols 67% Gateways 67% Applications & Services 67% Actuators 61% Database servers 61% Routers 61% Decision systems 56% Devices to interface and manage things 56% Cloud infrastructure/services 50% Smartphones/Tablets 50% Software 44% Sensitive information 39% LAN 39% Firewalls, IDS/IPS 33% WAN 28% VPN 22% 0% 10% 20% 30% 40% 50% 60% 70% 80% Figure 6: Asset criticality Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017 The main findings here are that the most critical assets are the sensors, then the device and network management controls and thirdly the communication protocols, the gateways and the applications and services, all of them marked as critical by at least two thirds or more of the experts interviewed. Therefore, when addressing security in IoT, those assets should be prioritised. Once again, these results are based on a horizontal approach; hence, they could vary depending on the different deployments and use cases. Anyhow, conducting an asset and risk assessment is key to determine the criticality of the assets and threats that affect a specific IoT environment. Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017

text: 3. Threats and risk analysis

text: The main objective of this chapter is to determine and list the main security threats, vulnerabilities, risk factors and attack scenarios that affect IoT devices and networks, taking the different levels of importance and criticality the interviewed experts provided for each threat, risk and attack scenario into consideration. Furthermore, the three most critical attack scenarios are developed in detail in order to underline their intricacies and propose specific security measures to counter their impact and adverse effects. Security incidents The number of security threats targeting IoT devices has increased over the last years. Figure 7 illustrates some of the main IoT security incidents that have been discovered and/or have taken place since 2009, so as to highlight how the number attacks on IoT have greatly increased. It should be noted that this list is not exhaustive, it includes only the main examples. Given the ever wider penetration of IoT across the entire spectrum of daily activities and critical infrastructures, the occurrence of cybersecurity incidents is bound to have an increasing rate. A more detailed description of each security incident can be found in Annex D. Figure 7: Indicative timeline of IoT security incidents Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017 Threat taxonomy As observed in the previous section, the number of attacks directly related to IoT has grown over the last few years reaching the point where it became mainstream news article in 2016 with the Mirai botnet attacks. These attacks, in their great majority, are related to devices that have been violated or to systems that have been compromised, increasing at the same time the number of hazards to be faced in IoT. Being consistent with the ENISA Threat Taxonomy , we depict in Figure 8 the threat taxonomy focused on IoT with some examples of attacks listed (non exhaustive listing). Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017 Figure 8: IoT Threat taxonomy Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017 Nevertheless, the different threats have different potential impacts, since they vary according to the use case scenarios. In the interviews, the IoT experts provided insight into the varying impact of the threats. The most relevant ones are shown in Figure 9. Figure 9: IoT threats impact The impact of each threat was determined by calculating a weighted average of the responses from the interviewees, which were based on a five-step scale that ranged from no importance to crucial importance. While Figure 9 provides a visual representation of each threat’s impact, Figure 10 depicts the exact result of the calculation, where values between 3 and 3.5 out of 5 represent medium-importance threats, values between 3.5 and 4 out of 5 represent high-importance threats, and values over 4 out of 5 represent crucialimportance threats. Values below 3 out of 5 represent low-importance and no-importance threat, but it should be noted that no threat got that rating. Moreover, it can be seen that the average impact is rated as high, since the value of the average impact is 3.7 out of 5.

text: Sensitive data leakage / modification of information 5 4,2 Weak passwords4,1 4 Eavesdropping 3,6 3 2 Counterfeit by malicious devices 4,2DDoS 3,0 1 Impact 0 Impact average 3,5 3,3 Attacks on privacy Network outage

text: Figure 10: Threat impact weighted average Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017 Table 3 briefly describes every threat identified in the threat taxonomy and the assets affected by them. CATEGORY THREAT DESCRIPTION ASSETS AFFECTED Software programs designed to carry out unwanted and - IoT devices unauthorised actions on a system without the consent of Malware - Other IoT Ecosystem devices the user, resulting in damage, corruption or information - Platform & Backend theft. Its impact can be high. Code designed to take advantage of a vulnerability in - IoT devices order to gain access to a system. This threat is difficult to Exploit Kits - Other IoT Ecosystem devices detect and in IoT environments its impact ranges from - Infrastructure high to crucial, depending on the assets affected. Attacks designed for a specific target, launched over a long period of time, and carried out in multiple stages. - Infrastructure Targeted The main objective is to remain hidden and to obtain as - Platform & Backend attacks much sensitive data/information or control as possible. - Information While the impact of this threat is medium, detecting them is usually very difficult and takes a long time. Nefarious activity / Abuse Multiple systems attack a single target in order to - IoT devices saturate it and make it crash. This can be done by making - Other IoT Ecosystem devices DDoS many connections, flooding a communication channel or - Platform & Backend replaying the same communications over and over. - Infrastructure This threat is difficult to discover, since a counterfeit Counterfeit by - IoT devices device cannot be easily distinguished from the original. malicious - Other IoT Ecosystem devices These devices usually have backdoors and can be used to devices - Infrastructure conduct attacks on other ICT systems in the environment. - IoT devices This threat affects both the privacy of the user and the Attacks on - Other IoT Ecosystem devices exposure of network elements to unauthorised privacy - Platform & Backend personnel. - Information - IoT Devices In this case, the objective is not to damage the devices, Modification of - Other IoT Ecosystem devices but to manipulate the information in order to cause information - Platform & Backend chaos, or acquire monetary gains. - Information Active eavesdropping attack, in which the attacker relays - Information Man in the messages from one victim to another, in order to make - Communications middle them believe that they are talking directly to each other - IoT devices Taking control of an existing communication session IoT - Information between two elements of the network. The intruder is communication - Communications able to sniff sensible information, including passwords. protocol - IoT devices The hijacking can use aggressive techniques like forcing hijacking - Decision making disconnection or denial of service. Unauthorised interception (and sometimes modification) - Information Interception of of a private communication, such as phone calls, instant - Communications information messages, e-mail communications - IoT devices Eavesdropping / - Information Passively obtain internal information about the network: Interception / Network - Communications Hijacking devices connected, protocol used, open ports, services in reconnaissance - IoT devices use, etc. - Infrastructure - Information Session Stealing the data connection by acting as a legitimate host - Communications hijacking in order to steal, modify or delete transmitted data. - IoT devices - Information Information Passively obtain internal information about the network: - Communications gathering devices connected, protocol used, etc. - IoT devices This attack uses a valid data transmission maliciously by - Information Replay of repeatedly sending it or delaying it, in order to - IoT devices messages manipulate or crash the targeted device. - Decision making Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017 Interruption or failure in the network supply, either Network intentional or accidental. Depending on the network - Infrastructure Outage segment affected, and on the time required to recover, - Communications the importance of this threat ranges from high to critical. Failures of Threat of failure or malfunction of hardware devices - IoT devices Outages devices - IoT devices Failure of Threat of failure of software services or applications - Platform & Backend system - Other IoT Ecosystem devices Loss of support Unavailability of support services required for proper - All assets services operation of the information system. - IoT devices Data / Sensitive Sensitive data is revealed, intentionally or not, to Damage / Loss - Other IoT Ecosystem devices information unauthorised parties. The importance of this threat can (IT Assets) - Platform & Backend leakage vary greatly, depending on the kind of data leaked. - Information The most common IoT devices are often vulnerable due - IoT devices to weak/default passwords, software bugs, and - Other IoT Ecosystem devices Software configuration errors, posing a risk to the network. This - Platform & Backend vulnerabilities threat is usually connected to others, like exploit kits, and - Infrastructure it is considered crucial. - Applications & Services Failures / Malfunctions - IoT devices Errors on an active element of the network caused by the - Other IoT Ecosystem devices Third parties misconfiguration of another element that has direct - Platform & Backend failures relation with it. - Infrastructure - Applications & Services - IoT devices These include events such as, floods, heavy winds, heavy - Other IoT Ecosystem devices Natural Disaster snows, landslides, among others natural disaster, which - Platform & Backend could physically damage the devices. - Infrastructure Disaster - Other IoT Ecosystem devices Environmental Disasters in the deployment environments of IoT - Platform & Backend Disaster equipment and causing their inoperability. - Infrastructure Device Tampering a device by for example taking advantage of - Communications modification bad configuration of ports, exploiting those left open. - IoT devices - IoT devices Physical attacks Device Incidents such devices theft, bomb attacks, vandalism or - Other IoT Ecosystem devices destruction sabotage could damage devices - Platform & Backend (sabotage) - Infrastructure Table 3: Threat taxonomy Examples of IoT cyber security attack scenarios The threats and risks previously listed in chapter 3.2 could be used by attackers to cause cascade effects and further damages at different levels in the infrastructures. The different attack scenarios and the level of importance of each attack have been gathered from the desktop research as well as the information provided by the experts who have contributed to the report. It is worth noting that the attacks may take place throughout the whole process, and the impact that attacks may have on each specific part of the process has also been analysed. The importance level provided for each sample attack scenario ranges from low and medium through high and crucial, representing the negative impact level these attacks could have in a real-life incident, according to the input of the experts interviewed. This information is synthesised in Table 4. Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017 ATTACK SCENARIOS IMPORTANCE LEVEL 1. Against the network link between controller(s) and actuators High – Crucial 2. Against sensors, modifying the values read by them or their threshold values and settings High – Crucial 3. Against actuators, modifying or sabotaging their normal settings High – Crucial 4. Against the administration systems of IoT High – Crucial 5. Exploiting protocol vulnerabilities High 6. Against devices, injecting commands into the system console High– Crucial 7. Stepping stones attacks Medium –High 8. DDoS using an IoT botnet Crucial 9. Power source manipulation and exploitation of vulnerabilities in data readings Medium –High 10. Ransomware Medium – Crucial Table 4: IoT attack scenarios For these scenarios, additional relevant feedback in the context of this report was received. Each section includes a brief description, the potential impact, and threats: 1. Against the network link between controller(s) and actuators Eavesdropping is a threat that allows an attacker to extract sensitive and operational information that can be used for multiple malicious activities, including later attacks against IoT systems. In Advanced Persistent Threat (APT) attacks, eavesdropping and information gathering comprise one of the first stages carried out in order to identify weak spots and potential entry/attack points.  Impact: the main effect is the leakage of data. Depending on the environment, the severity can be lower or greater, but it may also be signalling a larger attack in progress.  Threats related: eavesdropping and leakage of sensitive data. 2. Against sensors, modifying the values read by them or their threshold values and settings The attacker manipulates the configuration of the sensors, changing the threshold values established on the sensors, to allow out-of-range read values to be accepted when they should not, posing a severe threat to the systems and installations. As larger installations usually have multiple and redundant sensors, the attacker would have to compromise multiple sensors for the attack to be efficient; if only one were compromised, the readings could be compensated with the input from the rest of the sensors.  Impact: allowing sensors to report and accept incorrect values puts the IoT environment at risk; a malfunctioning sensor may allow a power spike to go through, physically damaging the systems.

text: 70 Depending on the target, the impact of the attack could range from medium through crucial. For instance, the impact of the ransomware attack against the digital key system of a hotel, example found in Figure 7 and in Annex D:, was not critical. Nevertheless, a ransomware the size of WannaCry (https://www.enisa.europa.eu/publications/info-notes/wannacry-ransomware-outburst) aimed against IoT infrastructures could have an extreme impact and affect systems at an international scale.

text: Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017  Threats related: attacks on privacy and leakages of sensitive data/modification of information. 3. Against actuators, modifying or sabotaging their normal settings Manipulation of the actuators’ configuration/parameters making them use wrong configurations, thresholds or data, and therefore affecting their normal behaviour by sabotaging their normal operation settings.  Impact: it varies depending on the actuators affected. It can affect production processes.  Threats related: network outage and counterfeit by malicious devices. 4. Against the administration systems of IoT An attacker tries to gain full control over the administration system of an IoT system or device, potentially compromising the whole environment. It can be quite successful if weak or default passwords are used. This type of attack comprises different stages/phases and it is usually launched in a covert manner. It should be noted that this type of attack should be taken into account for the entire lifecycle of the device.  Impact: the compromise, manipulation or interruption of certain IoT systems could affect many people, cause environmental issues and even extend to other systems, affecting their communications or even disabling them.  Threats related: weak passwords, exploit kits, attacks on privacy, malware and DDoS. 5. Exploit Protocol vulnerabilities This type of exploitation is usually the gateway to launch other types of attacks; it is a means to an end. Exploits are used to gain privileged unauthorised access to a system, which can lead to the installation of other malicious content or backdoors. It is used as part of an attack, regardless of whether the target is a single system/device or a whole network. It is difficult to detect these exploits, and it is much easier to detect the actions carried out after the exploit has been successful.  Impact: if successful, the exploit creates an entry point to a system, in some cases with elevated privileges; if not, the system is likely to crash or become unstable. This attack is always used as part of a larger attack, which could be a simple data theft or a complex APT.  Threats related: exploit kits, malware and APTs. 6. Against devices by injecting commands into the system console This type of attack takes place when an attacker injects and executes commands with privileges in a compromised system through its console.  Impact: if the attacker is able to inject commands into a device, he or she could manage to breach another machine in the environment. This would produce a cascade effect on the system, and the attacker would be able to use all these devices for malicious purposes.  Threats related: Exploit kits, DDoS and network outage. 7. Stepping stone attacks This type of attack is a common way to launch anonymous attacks. They are often used by network intruders to hide their identities, since they launch attacks not from their own computer but from intermediary hosts that they previously compromised.  Impact: if an attacker launches a stepping stone attack, he or she could compromise a collection of hosts, using them as stepping stones to relay attack commands.  Threats related: APTs, DDoS, counterfeit by malicious devices. Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017 8. DDoS using an IoT botnet This type of attack does not target IoT devices themselves, but instead it uses them to attack other devices, not necessarily IoT ones. Firstly, a malware automatically finds vulnerable Internet of Things devices, infecting and conscripting them into a botnet, which then can be used to mount DDoS attacks, flooding the target's servers with malicious traffic.  Impact: the target device or service will be flooded with malicious traffic, taking it down.  Threats related: exploit kits, DDoS and counterfeit by malicious devices. 9. Power source manipulation and exploitation of vulnerabilities in data readings These attacks focus on manipulating power sources and exploiting vulnerabilities to modify the power data read. An attacker can tamper with the device’s battery or power input cabling either physically, by manipulating the power source itself, or with malware, by manipulating the way a device reads the information coming from the power source in order to, for example, make the device believe the battery level is higher or lower than the actual level. Some types of smart devices may be dependent on batteries for their normal operation. This feature may seem like an advantage over the less usual cables but, far from this, it requires taking into account certain aspects of security.  Impact: physical tampering a battery can damage it, potentially causing the device not being able to operate at all. The manipulation of the way a device reads the charge level coming from the battery can lead to the device believing the battery level is higher than the real one, causing the device to run out of battery and shut down, or lower than the real one, causing the device to enter a powersaving mode of operation, affecting the performance of the device.  Threats related: malware, physical attacks. 10. Ransomware These attacks are carried out by a malware that perpetually blocks access to the victim's data unless a ransom is paid. Since these attacks are malware-based, they can be evaded by updating/patching vulnerable devices. This can be also done outside the IoT ecosystem, such as with the WannaCry attack that took place on May 2017 , where the patch for the vulnerability that WannaCry exploited was released months before the attack. The problem regarding IoT is the difficulty to update/patch the different devices - some of them do not even have the ability to be updated or patched.  Impact: there are many possible targets for ransomware within IoT – an attacker could take control of a smart thermostat in the middle of winter and demand payment before the heat can be turned on, he could hold power grids or hospitals systems for ransom, etc., putting people safety at risk.  Threats related: exploit kits, DDoS, malware, weak passwords. Critical attack scenarios During the interviews with experts and relevant stakeholders, the aforementioned attack scenarios regarding IoT environments were described and detailed. The experts were asked to rank the 10 example attack scenarios in terms of criticality and the following three were also the most worrisome ones for interviewees. Figure 11 depicts the average criticality of a given attack scenario based on the input gathered from the expert interviews. Again, the challenge lies in defining the criticality level of an attack on an IoT environment when doing so in a horizontal manner. Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017 Against the administration systems of IoT 88,89% Against sensors, modifying the values read by 84,72% them or their threshold values and settings Against devices, injecting commands 81,94% Against the network link between controller(s) 73,61% and actuators Against the information transiting the network 73,61% Against actuators, modifying or sabotaging their 69,44% normal settings Exploiting protocol vulnerabilities 62,50% Stepping stones attacks 58,33% Power source manipulation 58,33% 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% Figure 11: Attack scenario criticality The three attack scenarios that stand out are:  Attack Scenario 1: IoT administration system compromise  Attack Scenario 2: Value manipulation in IoT devices  Attack Scenario 3: Botnet / Commands Injection The following sections detail each of these scenarios, including their impact, the stakeholders involved, the cascade effect risk, the gaps, the countermeasures that can be applied to protect against them, and more technical details. The detailed description of each one of those countermeasures can be found in Annex A: and in Annex B:. 3.4.1 Attack scenario 1: IoT administration system compromise This attack covers an infection designed to take control over one or multiple IoT devices within an IoT environment, in order to manipulate or crash them and to be able to modify values, change their functioning/behaviour or deny access to them. This attack scenario is based on an Enterprise gateway 71,72 attack . As depicted in Figure 12, the first step is to gather information in the network about the different IoT devices used in the enterprise. Once an IoT device is identified and selected, the attacker gathers specific information about its vulnerabilities. The next step is to exploit the different vulnerabilities found in that device, and to compromise the network. After that, the attacker ensures the persistence of the access to the system by configuring a backdoor. At this point, the attacker only needs to update the system (e.g. with a modified firmware) for the device to be permanently compromised. This way, the attacker gains full control over the Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017 device – he/she gains the ability to see all the data and information the device has gathered and has remote access to use whenever he/she wants, etc. Figure 12: Attack 1 – IoT administration system compromised IMPACT Crucial: the compromise of an IoT administration system grants the attacker access to all the assets (devices, networks, etc.) which fall under the control of that administration system. When compromised, the attacker is capable of performing administrative tasks within those assets, such as extracting confidential information from them, making them malfunction and directly affecting the behaviour of the IoT environment, etc. Since a compromised administration system leads to several assets being compromised over a long period of time and without being detected, the impact of this attack can be critical. EASE OF DETECTION CASCADE EFFECT RISK Medium: the changes to an IoT administration system can be High: the risk entailed is that, once an IoT device belonging detected through a correct monitoring and a proper logging to a specific IoT network is compromised, it becomes very system. easy to compromise the rest. ASSETS AFFECTED STAKEHOLDERS INVOLVED Devices to interface with things COMPROMISE Devices to manage things IoT experts, software developers and manufacturers Smartphones / Tablets Information security experts Gateways IT/Security solutions architects SYSTEM Software Chief Information Security Officers (CISOs) Sensitive information IOT ATTACK STEPS (SAMPLE BASED ON A REAL-CASE ATTACK SCENARIO) 1. Gathering of information about the infrastructure 2. Identification of system components 3. The attacker gathers further information to identify the vulnerable system 4. The vulnerable system is identified 5. Exploitation of vulnerabilities to compromise first the system and then through the system the network 6. A backdoor is installed in order to maintain access to that system 7. The attacker ensures the IoT systems are updated with modified firmware either by downloading and updating the firmware instantly, or by modifying the repository of update files. This is done to grant the attacker exclusive access and restrict other remote accesses 8. Finally the attacker takes control over the IoT environment Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017 RECOVERY TIME / EFFORT GAPS AND CHALLENGES Medium: it depends on the perimeter of the assets Insecure design or development compromised and on the number of assets infected. It ranges Lack of proper product lifecycle management from a few hours to up to several days if critical systems are compromised. COUNTERMEASURES  GP-TM-04: Sign code cryptographically to ensure it has not been tampered after being signed as safe for the device, and implement run-time protection and secure execution monitoring to be sure malicious attacks do not overwrite code after it is loaded  GP-TM-05: Control the installation of software on operational systems, to prevent unauthenticated software and files being loaded onto it  GP-TM-06: Enable a system to return to a state that is known to be secure, after a security breach occurs or if an upgrade is not successful  Hardening assets:  GP-PS-11: Identify significant risks using a defence-in-depth approach  GP-TM-22: Ensure default passwords and even default usernames are changed during the initial setup, and that weak, null or blank passwords are not allowed  GP-TM-27: Limit the permissions of actions allowed for a given system by Implementing fine-grained authorisation mechanisms and using the Principle of least privilege (POLP): applications must operate at the lowest privilege level possible  GP-TM-23: Authentication mechanisms must use strong passwords or personal identification numbers (PINs), and should consider using two-factor authentication (2FA) or multi-factor authentication (MFA) like Smartphones, Biometrics, etc., and certificates  GP-TM-38: Guarantee the different security aspects -confidentiality (privacy), integrity, availability and authenticity- of the information in transit on the networks or stored in the IoT application or in the Cloud  GP-TM-55: Implement a logging system that records events relating to user authentication, management of accounts and access rights, modifications to security rules, and the functioning of the system  GP-TM-56: Implement regular monitoring to verify the device behaviour, to detect malware and to discover integrity errors Table 5: Attack 1 – IoT administration system compromise 3.4.2 Attack scenario 2: Value manipulation in IoT devices The manipulation of calibration parameters established for the sensors allows undesired values to be accepted when they should not, which poses a severe threat to critical systems. This attack targets the sensor processing and knowledge model levels of the control system of an industrial robot in an Industry 4.0 environment . Figure 13 describes this attack, which starts with the calibration of a robot sensing equipment after a configuration change or when connected to a controller. The calibration data initially stored in the sensing equipment is transmitted to the controller during the system boot. Since the robot uses its local copy of that data, an attacker can manipulate the calibration parameters, causing the robot to move erratically or unexpectedly (in decision making, wrong input values lead to wrong decisions).

text: See https://documents.trendmicro.com/assets/wp/wp-industrial-robot-security.pdf

text: Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017 Figure 13: Attack 2 – Value manipulation in IoT devices IMPACT High – Crucial: By allowing the sensors to report and accept incorrect values, the IoT environment is put at risk – a malfunctioning industrial robot can cause severe physical damage to whatever it is working with, and in the worst case scenario, to the people working with it. EASE OF DETECTION CASCADE EFFECT RISK Easy – Medium: its detection is between easy and medium Medium: The cascade effect risk is medium, but it can vary since an operator can see whether the outcome and the depending on the number of sensors compromised in the robot’s behaviour are correct or not. robot, and on the number of robots involved. ASSETS AFFECTED STAKEHOLDERS INVOLVED E Sensors IS M Actuators O IoT experts, software developers and manufacturers R Decision making P IT/Security solutions architects M Software O Sensitive information C EM ATTACK STEPS (SAMPLE BASED ON A REAL-CASE ATTACK SCENARIO) ST SY T 1. The robot programmer uploads code to aserver IO 2. The robot is connected to a controller or its configuration has changed 3. The sensing equipment is calibrated 4. The calibration data initially stored in the sensing equipment is transmitted to the controller during the system boot 5. The controller uses its local copy of the data 6. An attacker remotely or locally tampers with calibration parameters 7. Original and unmodified code is executed by the robot 8. The robot moves erratically or unexpectedly because the true error is different from the error that the controller knows RECOVERY TIME / EFFORT GAPS AND CHALLENGES Medium – High: depending on the number of sensors, and Insecure design or development the robots involved, the recovery time can range from a few Lack of awareness and knowledge days to weeks. COUNTERMEASURES Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017 GP-PS-10: Establish and maintain asset management procedures and configuration controls for key network and information systems GP-PS-11: Identify significant risks using a defence-in-depth approach GP-TM-15: Design with system and operational disruption in mind, preventing the system from causing unacceptable risk of injury or physical damage GP-TM-31: Measures for tamper protection and detection. Detection and reaction to hardware tampering should not rely on network connectivity GP-TM-54: Data input validation (ensuring that data is safe prior to use) and output filtering GP-TM-56: Implement regular monitoring to verify the device behaviour, to detect malware and to discover integrity errors GP-OP-09: Ensure the personnel practices promote privacy and security – train employees in good privacy and security practices Table 6: Attack 2 – Value manipulation in IoT devices 3.4.3 Attack scenario 3: Botnet / Commands injection This attack entails the exploitation of some vulnerability inside a device to inject commands and obtain administrator privileges, with the purpose of creating a botnet made up of those vulnerable IoT devices. A botnet is a network of automatic devices that interact to accomplish some distributed task. Due to the characteristic interconnection of IoT devices and their poor configuration, carrying out such an attack is simple. This attack scenario is based on the Mirai botnet , which has conducted several of the most forceful DDoS attacks in recent history, and has proven capable of attacking varied kinds of targets, from KrebsOnSecurity website to a whole country’s telecommunication infrastructure . Therefore, with potential targets such as a hazardous energy infrastructure, the impact of a Mirai’s attack can reach extremely critical levels. The steps to follow in order to carry out this type of attack are illustrated in Figure 14. The first one is scanning open ports in IoT devices that are accessible over the Internet, which are usually poorly protected by default usernames and passwords that, users never change. Once the attacker gains access to the device, he or she will inject commands into the device’s console in order to obtain administrator privileges. If the attacker succeeds in obtaining these permissions, he or she will then make the device connect to a Command and Control (C&C) under his or her control, to download and execute a malicious script. The script will then be executed, deleting itself afterward and running in-memory. Then, it will begin to spread, attacking the same way other vulnerable devices, in order to gather an IoT device army, conscripting them into a botnet, which the attacker will be able to control from a C&C centre, in order to launch distributed attacks conducted by the botnet. Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017 Figure 14: Attack 3 – Botnet / Commands injection IMPACT High – Crucial: The impact of the attacks carried out by a botnet ranges from high to critical, depending on the volume of the distributed attack, which is directly related to the number of compromised assets that are part of the botnet, and the criticality of the target. EASE OF DETECTION CASCADE EFFECT RISK Hard: due to the ignorance about the characteristics and Critical: this type of attack has a tremendous cascade effect. configuration of these devices, these attacks tend to be hard Once a device is infected, the goal is to identify other to detect and identify the source, which allows them to pass vulnerable devices to extend the network. undetected for long periods of time, and they are also complex to investigate and recover from. E IS ASSETS AFFECTED STAKEHOLDERS INVOLVED M O R Devices to interface with things P IoT experts, software developers and manufacturers M Devices to manage things O Information security experts Device and network management C IT/Security solutions architects Communications EM Chief Information Security Officers (CISOs) ST Software SY T ATTACK STEPS (SAMPLE BASED ON A REAL-CASE ATTACK SCENARIO) IO 1. The attacker scans open ports in devices belonging to an IoT network 2. If there are any open ports, the attacker tries to gain access to the device using weaknesses such as weak or default passwords, or through exploiting the test/debug modes 3. Once inside, the attacker injects commands in order to obtain administrator privileges 4. With these permissions, the attacker tries to connect the device to the Command and Control of the botnet 5. The attacker downloads and executes a malicious script 6. The script deletes itself and runs in-memory 7. Then, it will begin to spread, attacking other vulnerable devices in the same way, in order to gather an IoT device army, conscripting them into a botnet. 8. The attacker can now control the botnet from a Command and Control (C&C) centre, from where he or she will launch distributed attacks conducted by the botnet. RECOVERY TIME / EFFORT GAPS AND CHALLENGES Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017 High: the main issue is the amount of time it takes to detect Insecure design or development that the system that has been manipulated, which can take Lack of proper product lifecycle management several days/weeks, or even months in extreme cases COUNTERMEASURES  GP-TM-04: Sign code cryptographically to ensure it has not been tampered after being signed as safe for the device, and implement run-time protection and secure execution monitoring to be sure malicious attacks do not overwrite code after it is loaded  GP-TM-05: Control the installation of software on operational systems, to prevent unauthenticated software and files being loaded onto it  GP-TM-06: Restore Secure State - Enable a system to return to a state that is known to be secure, after a security breach occurs or if an upgrade is not successful  GP-TM-08: Enable security by default. Any applicable security features should be enabled by default, and any unused or insecure functionalities should be disabled by default  GP-TM-09: Establish hard to crack device individual default passwords  GP-TM-22: Ensure default passwords and even default usernames are changed during the initial setup, and that weak, null or blank passwords are not allowed  GP-TM-50: Ensure only necessary ports are exposed and available  GP-TM-56: Implement regular monitoring to verify the device behaviour, to detect malware and to discover integrity errors Table 7: Attack 3 – Botnet / Commands injection Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017

text: 4. Security measures and good practices

text: This chapter provides a detailed list of security measures and good practices, which aim to mitigate the threats, vulnerabilities and risks identified in the study that affect IoT devices and environments. These security measures and good practices have been defined with the aim to apply to the different IoT environments and deployments in a horizontal manner, instead of providing IoT vertical-specific security. Therefore, the security measures defined cover a wide range of security considerations, such as security by design, data protection, risk analysis, etc. The set of security measures / good practices of this report has been determined based on a very extensive and thorough desktop research, which took into account different security guidelines, standards, etc. The list of these resources can be found in Annex C:. The different security measures and good practices identified fall into several security domains defined for the report. This domain division’s purpose is to cover every IoT environment horizontally, so as to classify and define which security measures apply to which different IoT ecosystem areas. The proposed security domains are organised as follows:  Information System Security Governance & Risk Management: Includes security measures regarding information system security risk analysis, policy, accreditation, indicators and audit, and human resource security.  Ecosystem Management: Includes security measures regarding ecosystem mapping and ecosystem relations.  IT Security Architecture: Includes security measures regarding systems configuration, asset management, system segregation, traffic filtering and cryptography.  IT Security Administration: Includes security measures regarding administration accounts and administration information systems.  Identity and access management: Includes security measures regarding authentication, identification and access rights.  IT security maintenance: Includes security measures regarding IT security maintenance procedures and remote access.  Physical and environmental security  Detection: Includes security measures regarding detection, logging, and log correlation and analysis.  Computer security incident management: Includes security measures regarding information system security incident analysis and response, and incident report.  Continuity of Operations: Includes security measures regarding business continuity management and disaster recovery management.  Crisis Management: Includes security measures regarding crisis management organization and process. These security domains have been considered when developing the different security measures/good practices for IoT, which can be found below in points 4.1 through 4.3. The detailed description of each security measure/good practice and its security domain, along with the documents and references that have Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017 been analysed in order to extract it, can be found in Annex A: together with all the relevant examples. Additionally, in Annex B:, each security measure can be found mapped to the threats related to it. As mentioned earlier, these security domains classify the security measures based on which area of an IoT ecosystem they apply to. Apart from their area of application, each security measure can be arranged according to its nature – they can be policies that must be taken into account when developing the devices, organisational measures focused on the business and employees that need to be adopted by the organisation itself, and finally, technical measures aimed at reducing the potential risks that the IoT devices and other elements of the IoT ecosystem may be subject to. Accordingly, the identified IoT baseline security measures (denoted henceforth as GP-Good Practices) are presented here and arranged according to three main categories:  Policies (PS)  Organisational, People and Process measures (OP)  Technical Measures (TM) Policies The first set of security measures refers to policies that generally target information security and aim at making it more concrete and robust. These should be adequate for the organisation’s activity and must contain well documented information. In this context, the following security good practices have been defined. It is worth mentioning that when referring to security and privacy by design, the security measures should reflect the particularities and the context in which the IoT device or system will be deployed (for example, security by design will refer to different specifications when an IoT device at a home environment is considered, compared to the case of an IoT device in a critical infrastructure). As discussed, when it comes to IoT the cyber risk is context-dependent (i.e. based on the application scenario) and in this respect the security measures should be applied with this consideration in mind. 4.1.1 Security by design  GP-PS-01: Consider the security of the whole IoT system from a consistent and holistic approach during its whole lifecycle across all levels of device/application design and development, integrating security throughout the development, manufacture, and deployment.  GP-PS-02: Ensure the ability to integrate different security policies and techniques.  GP-PS-03: Security must consider the risk posed to human safety.  GP-PS-04: Designing for power conservation should not compromise security.  GP-PS-05: Design architecture by compartments to encapsulate elements in case of attacks.  GP-PS-06: For IoT hardware manufacturers and IoT software developers it is necessary to implement test plans to verify whether the product performs as it is expected. Penetration tests help to identify malformed input handling, authentication bypass attempts and overall security posture.  GP-PS-07: For IoT software developers it is important to conduct code review during implementation as it helps to reduce bugs in a final version of a product. 4.1.2 Privacy by design  GP-PS-08: Make privacy an integral part of the system.  GP-PS-09: Perform privacy impact assessments before any new applications are launched. Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017 4.1.3 Asset Management  GP-PS-10: Establish and maintain asset management procedures and configuration controls for key network and information systems. 4.1.4 Risk and Threat Identification and Assessment  GP-PS-11: Identify significant risks using a defence-in-depth approach.  GP-PS-12: Identify the intended use and environment of a given IoT device. Organisational, People and Process measures All businesses must have organisational criteria for information security. Their personnel practices need to promote good security, ensure the management of processes and safely operate the information in the organisation practices. Organisations should ensure that contractors and suppliers are responsible and accountable for the functions considered. In the event of an incident in the safety of the organisation, the organisation must be prepared (responsibilities, evaluation and response). 4.2.1 End-of-life support  GP-OP-01: Develop an end-of-life strategy for IoT products.  GP-OP-02: Disclose the duration and end-of-life security and patch support (beyond product warranty).  GP-OP-03: Monitor the performance and patch known vulnerabilities up until the “end-of-support|” period of a product’s lifecycle. 4.2.2 Proven solutions  GP-OP-04: Use proven solutions, i.e. well known communications protocols and cryptographic algorithms, recognized by the scientific community, etc. Certain proprietary solutions, such as custom cryptographic algorithms, should be avoided. 4.2.3 Management of security vulnerabilities and/or incidents  GP-OP-05: Establish procedures for analysing and handling security incidents.  GP-OP-06: Coordinated disclosure of vulnerabilities.  GP-OP-07: Participate in information-sharing platforms to report vulnerabilities and receive timely and critical information about current cyber threats and vulnerabilities from public and private partners.  GP-OP-08: Create a publicly disclosed mechanism for vulnerability reports, e.g. Bug Bounty programs. 4.2.4 Human Resources Security Training and Awareness  GP-OP-09: Ensure the personnel practices promote privacy and security – train employees in good privacy and security practices.  GP-OP-10: Document and monitor the privacy and security training activities.  GP-OP-11: Ensure that cybersecurity roles and responsibilities for all workforce are established and introduce personnel assignments in accordance with the specifics of the projects and security engineering needs. 4.2.5 Third-Party relationships  GP-OP-12: Data processed by a third-party must be protected by a data processing agreement.  GP-OP-13: Only share consumers’ personal data with third parties with express consent of the consumers, unless otherwise required and limited for the use of product features or service operations.  GP-OP-14: For IoT hardware manufacturers and IoT software developers it is necessary to adopt cyber supply chain risk management policies and to communicate cyber security requirements to its suppliers and partners. Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017 Technical Measures Evidently, the security measures and good practices need to consider and cover the technical elements, in order to diminish the vulnerabilities of IoT. Below we provide an overview of the necessary technical measures to preserve and protect the security of information in IoT. Since these are horizontal measures across vertical sectors/CIIs, given the particularities of each vertical, more concrete measures can be introduced for each vertical/CII. Applying these technical measures should take into account the particularities of the IoT ecosystem such as scalability, namely given the huge number of involved devices certain measures might need to be carried out at the level of specialised architectural components, e.g. gateways. 4.3.1 Hardware security  GP-TM-01: Employ a hardware-based immutable root of trust.  GP-TM-02: 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 storage of device identity and authentication means, 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. 4.3.2 Trust and Integrity Management  GP-TM-03: Trust must be established in the boot environment before any trust in any other software or executable program can be claimed.  GP-TM-04: Sign code cryptographically to ensure it has not been tampered with after signing it as safe for the device, and implement run-time protection and secure execution monitoring to make sure malicious attacks do not overwrite code after it is loaded.  GP-TM-05: Control the installation of software in operating systems, to prevent unauthenticated software and files from being loaded onto it.  GP-TM-06: Enable a system to return to a state that was known to be secure, after a security breach has occured or if an upgrade has not been successful.  GP-TM-07: Use protocols and mechanisms able to represent and manage trust and trust relationships. 4.3.3 Strong default security and privacy  GP-TM-08: Any applicable security features should be enabled by default, and any unused or insecure functionalities should be disabled by default.  GP-TM-09: Establish hard to crack, device-individual default passwords. 4.3.4 Data protection and compliance  GP-TM-10: Personal data must be collected and processed fairly and lawfully, it should never be collected and processed without the data subject’s consent.  GP-TM-11: Make sure that personal data is used for the specified purposes for which they were collected, and that any further processing of personal data is compatible and that the data subjects are well informed.  GP-TM-12: Minimise the data collected and retained.  GP-TM-13: IoT stakeholders must be compliant with the EU General Data Protection Regulation (GDPR).  GP-TM-14: Users of IoT products and services must be able to exercise their rights to information, access, erasure, rectification, data portability, restriction of processing, objection to processing, and their right not to be evaluated on the basis of automated processing. Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017 4.3.5 System safety and reliability  GP-TM-15: Design with system and operational disruption in mind, preventing the system from causing an unacceptable risk of injury or physical damage.  GP-TM-16: Mechanisms for self-diagnosis and self-repair/healing to recover from failure, malfunction or a compromised state.  GP-TM-17: Ensure standalone operation - essential features should continue to work with a loss of communications and chronicle negative impacts from compromised devices or cloud-based systems. 4.3.6 Secure Software / Firmware updates  GP-TM-18: 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. hardcoded credentials), that it is signed by an authorised 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.  GP-TM-19: Offer an automatic firmware update mechanism.  GP-TM-20: Backward compatibility of firmware updates. Automatic firmware updates should not modify user-configured preferences, security, and/or privacy settings without user notification. 4.3.7 Authentication  GP-TM-21: Design the authentication and authorisation schemes (unique per device) based on the system-level threat models.  GP-TM-22: Ensure that default passwords and even default usernames are changed during the initial setup, and that weak, null or blank passwords are not allowed.  GP-TM-23: Authentication mechanisms must use strong passwords or personal identification numbers (PINs), and should consider using two-factor authentication (2FA) or multi-factor authentication (MFA) like Smartphones, Biometrics, etc., on top of certificates.  GP-TM-24: Authentication credentials shall be salted, hashed and/or encrypted.  GP-TM-25: Protect against ‘brute force’ and/or other abusive login attempts. This protection should also consider keys stored in devices.  GP-TM-26: Ensure password recovery or reset mechanism is robust and does not supply an attacker with information indicating a valid account. The same applies to key update and recovery mechanisms. 4.3.8 Authorisation  GP-TM-27: Limit the actions allowed for a given system by Implementing fine-grained authorisation mechanisms and using the Principle of least privilege (POLP): applications must operate at the lowest privilege level possible.  GP-TM-28: Device firmware should be designed to isolate privileged code, processes and data from portions of the firmware that do not need access to them. Device hardware should provide isolation concepts to prevent unprivileged from accessing security sensitive code. 4.3.9 Access Control - Physical and Environmental security  GP-TM-29: Data integrity and confidentiality must be enforced by access controls. When the subject requesting access has been authorised to access particular processes, it is necessary to enforce the defined security policy.  GP-TM-30: Ensure a context-based security and privacy that reflects different levels of importance.  GP-TM-31: Measures for tamper protection and detection. Detection and reaction to hardware tampering should not rely on network connectivity. Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017  GP-TM-32: Ensure that the device cannot be easily disassembled and that the data storage medium is encrypted at rest and cannot be easily removed.  GP-TM-33: 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 they cannot be used to maliciously access the devices. In general, lock down physical ports to only trusted connections. 4.3.10 Cryptography  GP-TM-34: Ensure a proper and effective use of cryptography to protect the confidentiality, authenticity and/or integrity of data and information (including control messages), in transit and in rest. Ensure the proper selection of standard and strong encryption algorithms and strong keys, and disable insecure protocols. Verify the robustness of the implementation.  GP-TM-35: Cryptographic keys must be securely managed.  GP-TM-36: Build devices to be compatible with lightweight encryption and security techniques.  GP-TM-37: Support scalable key management schemes. 4.3.11 Secure and trusted communications  GP-TM-38: Guarantee the different security aspects -confidentiality (privacy), integrity, availability and authenticity- of the information in transit on the networks or stored in the IoT application or in the Cloud.  GP-TM-39: Ensure that communication security is provided using state-of-the-art, standardised security protocols, such as TLS for encryption.  GP-TM-40: Ensure credentials are not exposed in internal or external network traffic.  GP-TM-41: Guarantee data authenticity to enable reliable exchanges from data emission to data reception. Data should always be signed whenever and wherever it is captured and stored.  GP-TM-42: Do not trust data received and always verify any interconnections. Discover, identify and verify/authenticate the devices connected to the network before trust can be established, and preserve their integrity for reliable solutions and services.  GP-TM-43: IoT devices should be restrictive rather than permissive in communicating.  GP-TM-44: Make intentional connections. Prevent unauthorised connections to it or other devices the product is connected to, at all levels of the protocols.  GP-TM-45: Disable specific ports and/or network connections for selective connectivity.  GP-TM-46: Rate limiting. Controlling the traffic sent or received by a network to reduce the risk of automated attacks. 4.3.12 Secure Interfaces and network services  GP-TM-47: Risk Segmentation. Splitting network elements into separate components to help isolate security breaches and minimise the overall risk.  GP-TM-48: Protocols should be designed to ensure that, if a single device is compromised, it does not affect the whole set.  GP-TM-49: Avoid provisioning the same secret key in an entire product family, since compromising a single device would be enough to expose the rest of the product family.  GP-TM-50: Ensure only necessary ports are exposed and available.  GP-TM-51: Implement a DDoS-resistant and Load-Balancing infrastructure.  GP-TM-52: Ensure web interfaces fully encrypt the user session, from the device to the backend services, and that they are not susceptible to XSS, CSRF, SQL injection, etc.  GP-TM-53: Avoid security issues when designing error messages. 4.3.13 Secure input and output handling  GP-TM-54: Data input validation (ensuring that data is safe prior to use) and output filtering. Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017 4.3.14 Logging  GP-TM-55: Implement a logging system that records events relating to user authentication, management of accounts and access rights, modifications to security rules, and the functioning of the system. Logs must be preserved on durable storage and retrievable via authenticated connections. 4.3.15 Monitoring and Auditing  GP-TM-56: Implement regular monitoring to verify the device behaviour, to detect malware and to discover integrity errors.  GP-TM-57: Conduct periodic audits and reviews of security controls to ensure that the controls are effective. Perform penetration tests at least biannually. Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017

text: 5. Gaps analysis

text: This section provides an analysis of the main gaps in relation to cyber security in IoT. A critical part to address cyber security in IoT is the identification and definition of gaps -the space between the present state and the desired state- so as to determine what steps need to be taken in order to close those gaps, namely, to move from the current immature state to the future and more mature state. In the interviews conducted with IoT experts there was a common denominator – in terms of maturity, the security in IoT is in an initial stage of development. The following gaps were identified as being the most prominent ones by the experts who took part in the study and by conducting a comparative analysis of existing IoT security resources as listed in Annex C. We examine the gaps by taking into account two aspects, namely beginning with the analysis of the barriers and ending with the changes that need to be considered to improve and guarantee security in IoT. We also outline the relevant challenges that act as hindering factors towards a more mature IoT security landscape. The ultimate goal of addressing the IoT security and safety gaps is to ensure the priotection of all assets, to preserve the required level of privacy, as well as attain and sustain a high level of resiliency against cyber attacks thus ensures physical safety alongside cyber security. Gap 1: Fragmentation in existing security approaches and regulations Currently, there is no common EU-wide approach to cyber security in IoT, or a common multi-stakeholder model on cyber security. In the interviews carried out throughout the study, the majority of experts considered the lack of mature security frameworks, and the breadth of security considerations to take into account, big barriers for the improvement of security. Therefore, most companies and manufacturers are taking their own approach when implementing security into IoT, resulting in a lack or slow embracement of standards to guide the adoption of IoT security measures and good practices. Whereas stringent measures and legislation introduced by regulators could become restrictive for security research, development and innovation, it could be more effective if initiatives were put in place to stimulate the development of security in private companies. Nevertheless, the key to rapid progress in this area is to get the public and private sectors to work together and understand that security does not only concern a single manufacturer, customer or IT professional , but rather everyone involved in the process. Cybersecurity is a shared responsibility. The fragmentation of the regulations also poses a barrier when Critical Information Infrastructures are seen hand in hand with the IoT world, since there is no regulation that forces security measures and protocols in the different levels of an IoT ecosystem, including the devices, the network, etc. This could potentially allow for a more complete integration of safety and security in the development lifecycles. Conversely, the application of one-size fits all standards across the IoT ecosystem might be seen as a hindering factor for innovation and research in the area. As discussed throughout the report, one needs to also consider the fact that different application areas have diverse security requirements. Another significant problem to tackle is that of unclear liabilities – there is a barrier of non-responsibility, both moral and legal, which can be mitigated or solved by enforcing responsibilities. There has been no chance to enforce a perfect isolation between the different elements of an IoT ecosystem, which will Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017 unavoidably be developed by different manufacturers and/or operated by different parties. In this context, there is a need to clarify the liability of each actor in case of a security event. Gap 2: Lack of awareness and knowledge There is a gap in relation to the increasing move towards connected and interdependent systems and devices as far as knowledge is concerned. In the interviews with IoT experts, differences in fundamental terminology were encountered, such as the difference between the concepts of safety and security. Security experts are more commonly familiar with “business IT” security, but not with IoT security. There is an overall lack of awareness regarding the need of security in IoT devices. Even more worrisome is the lack of knowledge regarding the threats they are exposed to – most IoT consumers do not have a basic understanding of their IoT devices and the impact on their environment. This may result in the devices not being updated, with a subsequent breach of security. Moreover, companies should train their employees in good security practices, recognising that technological expertise does not necessarily equate with security expertise. In general, there is a need to properly educate a new generation of consumers, developers, manufacturers, etc. about the use and the security risks posed by IoT, and how to be prepared. It is also necessary to train them in both safety and cyber security to increase awareness. Many security incidents could be avoided if developers and manufacturers were aware of the risks they face on a daily basis, considering not only those affecting IoT devices but also those affecting the whole IoT environment. This is becoming a common need in order to raise awareness about current threats and risks and to provide knowledge on how to prevent, protect and act in case of a security incident. Gap 3: Insecure design and/or development  Lack of strong authentication and authorisation:  No validation or signing of firmware updates,  Software updates without server authentication and file trust verification,  No secure boot mechanisms.  Lack of hardening:  No data execution prevention or attack mitigation technologies used on the firmware,

text: 77 See http://otalliance.actonsoftware.com/acton/attachment/6361/f-008e/1/-/-/-/-/IoT Framework Resource Guide.pdf 78 See http://www.gsma.com/connectedliving/wp-content/uploads/2016/11/CLP.12-v1.1.pdf 79 See https://cloudsecurityalliance.org/download/new-security-guidance-for-early-adopters-of-the-iot/ 80 See https://www.symantec.com/security-center/threat-report

text: Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017  Public vulnerabilities (DNS proxy, HTTP service…) left unfixed,  Some services are exposed through different entry points, with unnecessary communication ports left open – services such as Telnet or ssh are sometimes bound to all network interfaces,  Weak passwords policies or default passwords left unchanged,  Configuration flaws.  Lack of diagnosis / response capabilities. Gap 4: Lack of interoperability across different IoT devices, platforms and frameworks The great majority of IoT ecosystems include IoT devices connected with legacy systems, especially in the case of Critical Information Infrastructures. Moreover, as previously mentioned, due to the lack of a common regulation, most companies and manufacturers are taking their own approach when designing IoT devices, causing interoperability issues between devices from different manufacturers as well as the emergence of different security models, incompatible concepts and taxonomies, etc. Therefore, it is very important to develop measures that ensure a correct and secure interconnection and interoperability between the IoT environment and legacy systems, and the other IoT devices manufactured by third-parties. Most IoT devices use proprietary protocols designed by their manufacturers in order to interconnect devices. While this is not an issue for devices from the same manufacturer, it becomes a problem when interconnecting devices from different manufacturers. This requires the development and use of standard protocols that need to be supported by all manufacturers to ensure a good level of interoperability with the least efficiency and security loss. A good practice in this regard is to avoid the use of close-source and proprietary protocols, as their security cannot be verified, and many incidents have already proven that security through obscurity does not necessarily equate proper security coverage. In the same spirit, apart from protocols, the use of common frameworks can also help to improve the efficiency and security of the devices when interconnecting several ones from different manufacturers. Gap 5: Lack of economic incentives The main IoT manufacturers and vendors usually consider functionality and usability much more important than implementing secure design and programming. Their economic interests are not aligned with spending much money on security, and in some cases they do not consider security at all. The main reason for these companies no to dedicate much of their budget to security is the general perception that there is no direct return-on-investment for security, which can be attributed to the economic cost and the difficulty to assess the financial impact of hypothetical security weaknesses. This is worsened by the lack of economic incentives that would help to improve security, such as economic benefits (e.g. more grants to integrate better security in the devices), resources, perceived reputation, etc. Apart from this, the economic support is only accessible through very competitive programs such as H2020 in the case of research and development. In general, the IoT experts interviewed agree that the different risks, threats and hazards are usually underestimated and left out because of budgetary issues – there is a tendency to handle security concerns a posteriori of incidents. Gap 6: Lack of proper product lifecycle management In general, safety measures are found lacking from the design phase to its later development. This demonstrates the need for a proper product lifecycle management of the different assets that compose a Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017 given IoT environment, since the devices and networks are interconnected and, in most cases, exposed to the Internet, where they can be targeted by many and diverse threats. IoT comprises such a variety of products that, if left unattended, it makes the entire surface of the traditional supply chain vulnerable. IoT expands the global attack surface and it is everyone's responsibility to manage the risks. The different devices and products will have to evolve in a secure way to consistently provide, through their whole lifecycle, the solution for which they were created. In this process, it is necessary to involve the vendors and, since they are in charge of designing and developing the devices, they are in an ideal position to implement the changes needed – they are able to proficiently and cost-efficiently include new security features or characteristics. This, however, is not only dependent on manufacturers adding these new features, but also on organisations accepting the related costs; therefore, a balance between security and cost must be maintained. Through their lifecycle, IoT devices must be able to be patched and updated rapidly to ensure their correct operation and to amend all the vulnerabilities that are continuously being discovered. As mentioned before, in consumer environments most IoT users do not have a basic understanding of their IoT devices and their impact on their environment, which may result in the devices not being updated and a subsequent breach of security. In addition, one important phase of the device lifecycle management is the deployment phase. Best practices for IoT deployment could be defined. They may include recommendations for specific configurations of devices and networks or the need to implement cybersecurity monitoring systems to detect anomalies in the deployed infrastructure. Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017

text: 6. High-level recommendations to improve IoT cybersecurity

text: This chapter includes a list of high-level recommendations for developers, operators and security experts that will help them to improve the security level of IoT devices and communications among them. The recommendations discussed here concern stakeholders that span the entire IoT spectrum and aim to address the gaps defined in Chapter 5. Recommendations The recommendations proposed are listed in the following table, and they have been further developed in section 6.2: ID DESCRIPTION 1 Promote harmonization of IoT security initiatives and regulations 2 Raise awareness for the need for IoT cybersecurity 3 Define secure software/hardware development lifecycle guidelines for IoT 4 Achieve consensus for interoperability across the IoT ecosystem 5 Foster economic and administrative incentives for IoT security 6 Establishment of secure IoT product/service lifecycle management 7 Clarify liability among IoT stakeholders Table 8: IoT Security Recommendations Detailed recommendations 6.2.1 Promote harmonization of IoT security initiatives and regulations Recommendation intended for: IoT industry, providers, manufacturers, associations The current fragmentation of IoT security guidelines, initiatives, standards and other schemes needs to be addressed. A first and solid step in the direction is to define a list of best practices and guidelines for IoT security and privacy, which can be used as a baseline for the development and deployment of IoT systems in the market (for example consult reports from AIOTI and ECSO). The current ENISA report provides such a list and goes one step further by categorizing all security measures according to a well-defined and structured set of security domains. In terms of harmonization of standards, it is interesting to note that the notion of standard is appreciated and supported by the industry but groups of stakeholders have different R&D chains and this inherently drives fragmentation. The recommendation to counter this fragmentation refers to establishing a set of practices, guidelines and security requirements in IoT, which are common over Europe. The Commission should be facilitator of this process and this ENISA report can serve as the springboard for related efforts. Subsequently, each sector can focus on defining the specific sets of practices, guidelines, requirements for its own needs based on the particular context and risk factors inherent in each sector. European Commission and member states government could drive the coordination and collaboration of stakeholders (industry, users) and ENISA can be an important facilitator in this process. Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017 The procurement process is another means to impose harmonization of baseline standards and requirements for IoT systems. The harmonization should consider that there are many different sectors (e.g. energy, transportation) , so harmonization should be first achieved within each sector. 6.2.2 Raise awareness for the need for IoT cybersecurity Recommendation intended for: IoT industry, providers, manufacturers, associations, academia, consumer groups, regulators Cybersecurity is a shared responsibility among all involved stakeholders. It is thus essential for thse stakeholders to have a thorough understanding of related risks and threats, as well as ways to secure and protect against them. Raising awareness is therefore of paramount importance and initiatives to do so are highly recommended. As evidenced by the growing threat landscape and the numerous security incidents concerning IoT, there is lack of knowledge present within IoT developers, industries as wll as end users and consumers. To overcome such deficiency it is important to define targeted recommendations for all three stakeholder categories, namely:  Security education and training needs to be established in industries, including knowledge of stateof-the-art, best practices, reference architectures and availability of building blocks, methodologies and tools for secure IoT systems.  End users and consumers have to be educated to be able to make informed decisions when buying IoT devices and systems. Campaigns raising awareness for IoT security are thus highly important, also in order to be able to maintain a basic level of cyber hygiene for the security of the “Things” that they have purchased or are operating. The role and initiatives of consumer rights associations should be highlighted in this respect.  Among the developer community, awareness needs to be raised to adopt fundamental security principles that are cross vertical rather than being tied to any silo industry. Corporate trainings focused on IoT security are also beneficial and should be pursued. Similarly, initiatives like café scientific and cyber security clinics can prove to be effective.Lastly, trainings and courses at schools and universities (considering localisation to reach a wider audience) will further promote a better understanding of IoT security among the younger generation and thus in the long-term contributed to raising awareness. 6.2.3 Define secure software/hardware development lifecycle guidelines for IoT Recommendation intended for: IoT developers, platform operators, industry, manufacturers Developers, manufacturers and providers of IOT products and solutions should integrate and adopt a secure software development lifecycle (SSDLC) for their IoT offerings and incorporate relevant processes in their operations. Security must be implemented as a whole, at the application level, and in each of the phases of the SDLC. It is therefore important to encourage more companies to offer secure components that are at the same time usable for developers and end users/consumers. The notions of security and privacy by default and security and privacy by design naturally emerge as being foundation cornerstones of IoT security. Evidently, it is challenging to apply these concepts in several different environments that will have particular characteristics. In IoT the cyber risk is context-dependent (i.e. based on the application scenario) and in this respect the principles of security and privacy by design should be applied with this consideration in mind. Following relevant initiatives from other, more mature IT sectors can prove to be beneficial in adopting such principles for the IoT ecosystem. Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017 As far as developers are concerned, secure by design hackathons and use of best practice cookbooks for IoT security can greatly enhance their perception of using principle of security and privacy by default and by design. The lessons learned from such exercises would assist developers in applying corresponding techniques within their projects and products. When focussing on companies, the use of proper security processes and well-defined and widely accepted tools (e.g. standards, checklists) for IoT security would strongly promote the cause for IoT security by default and by design. 6.2.4 Achieve consensus for interoperability across the IoT ecosystem Recommendation intended for: IoT industry, providers, manufacturers, associations, regulators The issue of interoperability is very pertinent to the IoT ecosystem due to the very large scale and penetration of the IoT ecosystem, the long and complex supply chains and the numerous involved stakeholders. Ensuring and fostering interoperability of IoT devices, platforms and frameworks, as well as security practices is therefore an essential element of IoT security and should thus be encouraged. Recommendations that will undoubtedly assist in this direction include:  Encourage the use of open interoperability frameworks that incorporate security  Provide transparency on the security of interoperability frameworks  Promote open and accessible interoperability laboratories and testbeds for security It should be noted that said recommendations are indicative and continuous efforts towards promoting interoperability in the context of end-to-end and consistent cybersecurity should be pursued. 6.2.5 Foster economic and administrative incentives for IoT security Recommendation intended for: IoT industry, associations, academia, consumer groups, regulators It is clear that lack of security impacts business continuity and this is indeed the case also for IoT that is driven by R&D activities and a rush to push products and services in the market. In this respect, business continuity can serve as a driver for justifying costs in cyber security solutions. Moreover, market demands on cybersecurity are somewhat low because of the lack of consumer perception in the added value of cybersecurity. Consumer involvement is quite important and it should be supported more. Communication campaigns should be implemented by the government (e.g., the Commission, member states) in order to increase and sustain said perception and thus inherently necessitate the adoption of further mechanisms to promote IoT cybersecurity. In the case of IoT, competitive advantage is currently placed and focussed on the time to market rather than secure to market. This balance should be shifted so that a specific level of security and privacy before market deployment is encouraged. Defining security frameworks supported by baseline security measures can be a way forward in this direction. Use of other schemes such as certification and labelling can also encourage better understanding and transparency in terms of IoT security and thus should be considered (also benefitting end users and consumers in educating them and making them more aware of IoT security), albeit in a context and risk specific manner per use case/application sector. Subject to such approaches, subsequently regulative efforts and initiatiaves could then be put in place to follow the same path. 6.2.6 Establishment of secure IoT product/service lifecycle management Recommendation intended for: IoT developers, platform operators, industry, manufacturers Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017 Security plays an important role within all the phases of an IoT product’s/service’s lifecycle. These phases include design, development, testing, production, deployment, maintenance, end-of-support, and end-oflife (i.e. decommissioning). It is recommeneded that specific, focussed and targeted security processes be defined for all these phases. Furthermore, security processes have to be properly implemented. In order to satisfy this need, fundamental security requirements and building blocks have to be specified to be available within each phase. A noteworthy aspect involves security updates that constitute a significant issue in the context of IoT. After deployment, security updates need to be provided where practically possible whithout special knowledge requirements or financial obligations on the end user/consumer within a defined term and conditions until “end-of-support”. The latter must be clearly defined by the manufacturer/provider of the IoT product and must be clearly communicated to the end user/consumer. 6.2.7 Clarify liability among IoT stakeholders Recommendation intended for: IoT industry, regulators As identified by the interviews with the experts a very important issue when IoT is considered is that of liability. It is of particular importance in the IoT domain, since the cyber-physical nature of IoT relates and tightly binds security to safety. The question of liability needs to be addressed. The question of where liability may fall lies between the different and diverse stakeholders of the IoT ecosystem, such as developers, manufacturers, providers, vendors, aftermarket support operators, third party providers and the end users, to name a few. The liability issues have to be addressed in the context of European and national legislation and case law. Where gaps are identified in said legislation, these should be addressed. Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017

text: Glossary

text: 6LoWPAN IPv6 over Low Power Wireless Personal Area Network APT Advanced Persistent Threat AMQP Advanced Message Queuing Protocol BLE Bluetooth Low Energy CASB Cloud Security Access Broker CARP Channel-Aware Routing Protocol CII Critical Information Infrastructure CIIP Critical Information Infrastructure Protection CISO Chief Information Security Officer CoAP Constrained Application Protocol DDS Data Distribution Service (D)DoS (Distributed) Denial of Service IIC Industrial Internet Consortium ICT Information and Communication Technology IoT Internet of Things IoTSEC Internet of Things SECurity IIoT Industrial Internet of Things LPWAN Low Power Wide Area Network M2M Machine-to-Machine MQTT Message Queue Telemetry Transport NB-IoT NarrowBand-IoT NFC Near Field Communication QoS Quality of Service RBAC Role-Based Access Control RFID Radio Frequency Identification RPL Routing Protocol for Low-Power and Lossy Networks Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017 SME Small and medium-sized enterprise SDN Software-Defined Networking VPN Virtual Private Network WAF Web Application Firewall WLAN Wireless Local Area Network WPAN Wireless Personal Area Network WWAN Wireless Wide Area Network XMPP eXtensible Messaging and Presence Protocol Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017

text: Annex A: Detailed Security measures / Good practices

text: SECURITY MEASURES / GOOD PRACTICES SECURITY DOMAIN REFERENCES

text: - ISO27001 #A14. System acquisition, development and maintenance GP-PS-01: Consider the security of the whole IoT system in a - NIST SP 800-53 - System And Services Acquisition Control Family (SA) Ecosystem consistent and holistic approach along its whole lifecycle across all - NIST Framework for Improving Critical Infrastructure Cybersecurity Management levels of device/application design and development, integrating - OWASP Security by Design Principles security throughout the development, manufacturing, and - DG Commissioned Study - Definition of a Research and Innovation Policy Leveraging Cloud IT Security Architecture deployment Computing and IoT Combination -

text: Article 29

text: Data Protection Working Party - Opinion 8/2014 on the on Recent Developments on the Internet of Things GP-PS-02: Ensure the ability to integrate different security policies - U.S. Department of Homeland Security - Strategic Principles For Securing The Internet Of Things Ecosystem and techniques, so as to ensure a consistent security control over the (IoT) Management variety of devices and user networks in IoT - U.S. Department of Commerce, National Telecommunications and Information Administration,

text: internet policy task force & digital economy leadership team - fostering the advancement of the internet of things Physical and - U.S. Federal Communications Commission, Public Safety & Homeland Security Bureau - FCC GP-PS-03: Security must consider the risk to human safety environmental security White Paper, Cybersecurity Risk Reduction - EC Alliance for Internet of Things Innovation (AIOTI) - FTC - Internet of Things: Privacy & Security in a Connected World Security by GP-PS-04: Design for power conservation should not compromise - Cloud Security Alliance (CSA) - New Security Guidance for Early Adopters of the IoT design IT Security Architecture security - IoT Security Foundation (IoTSF) - GSM Association (GSMA) - IoT Security Guidelines - Atlantic Council (Brent Scowcroft Center On International Security) - Smart Homes and the GP-PS-05: Design architecture by compartments to encapsulate Internet of Things IT Security Architecture - IETF (Internet Engineering Task Force) - IETF RFC 7452 Architectural Considerations in Smart elements in case of attacks Object Networking - IETF (Internet Engineering Task Force) - Best Current Practices for Securing Internet of Things GP-PS-06: For IoT hardware manufacturers and IoT software (IoT) Devices developers it is necessary to implement test plans to verify whether - OASIS (Organization for the Advancement of Structured Information Standards) - Technical the product performs as it is expected. Penetration tests help to IT security maintenance Committees identify malformed input handling, authentication bypass attempts - ISACA - Performing a Security Risk Assessment and overall security posture. - AIOTI. Digitisation of Industry Policy Recommendations - International Telecommunication Union (ITU) - Unleashing the potential of the Internet of Things - AT&T Cybersecurity Insights - Exploring IoT Security Volume 2 GP-PS-07: For IoT software developers it is important to conduct - Symantec - An Internet of Things Reference Architecture code review during implementation as it helps to reduce bugs in a IT security maintenance - Microsoft - Cybersecurity Policy For The Internet Of Things final version of a product. - Infineon - Hardware Security for Smart Grid End Point Devices

text: Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017 SECURITY MEASURES / GOOD PRACTICES SECURITY DOMAIN REFERENCES

text: - ISO27001 #A14. System acquisition, development and maintenance - NIST SP 800-53 - System And Services Acquisition Control Family (SA) - OWASP Security by Design Principles - DG Commissioned Study - Definition of a Research and Innovation Policy Leveraging Cloud GP-PS-08: Privacy must be a guiding principle when designing and Information System developing systems, in order to make privacy an integral part of the Security Governance & Computing and IoT Combination system. Risk Management - ARTICLE 29 Data Protection Working Party - Opinion 8/2014 on the on Recent Developments on the Internet of Things - EC Alliance for Internet of Things Innovation (AIOTI) - IOT-A (Internet of Things Architecture) - U.S. Department of Commerce, National Telecommunications and Information Administration, Internet Policy Task Force & Digital Economy Leadership Team - Fostering The Advancement Of Privacy by design The Internet Of Things GP-PS-09: Perform privacy impact assessments before any new - U.S. Federal Communications Commission, Public Safety & Homeland Security Bureau - The President’s National Security Telecommunications Advisory Committee - NSTAC Report to applications are launched, using a top‐down decomposition method that requires first answering three fundamental questions: Information System the President on the Internet of Things - Cloud Security Alliance (CSA) - Future-proofing the Connected World: 13 Steps to Developing - Where is the targeted application deployed (Legal constraints Security Governance & Secure IoT Products and cultural significance) Risk Management - For what purpose (Scope) - Cloud Security Alliance (CSA) - New Security Guidance for Early Adopters of the IoT - GSM Association (GSMA) - IoT Security Guidelines - For which scenarios (Business requirements) - International Electrotechnical Commission (IEC) - IEC White Paper on “IoT 2020: Smart and secure IoT platform” - AIOTI. Digitisation of Industry Policy Recommendations - ISO27001 #A8. Asset Management - NIST SP 800-53 - PE-20 Asset Monitoring And Tracking - U.S. Department of Health and Human Services Food and Drug Administration (FDA) Center for Devices and Radiological Health - Postmarket Management of Cybersecurity in Medical Devices Guidance for Industry and Food and Drug Administration Staff GP-PS-10: Establish and maintain asset management procedures and - GSM Association (GSMA) - IoT Security Guidelines configuration controls for key network and information systems, to Asset IT Security Architecture identify and authenticate of the assets involved in the IoT Service (i.e. Management Gateways, Endpoint devices, home network, roaming networks, service platforms, etc.).

text: - ISO27001 #6. Planning GP-PS-11: Identify significant risks using a defence-in-depth - NIST SP 800-30 approach. Conduct end-to-end risk assessments that account for - NIST SP 800-53 - Risk Assessment Control Family (SA) both internal and third-party vendor risks, where possible. - NIST Framework for Improving Critical Infrastructure Cybersecurity Developers and manufacturers should include vendors and suppliers - OWASP Testing Guide v4 - Risk Rating Methodology in the risk assessment process, which will create transparency and - IOT-A (Internet of Things Architecture) enable them to gain awareness of potential third-party vulnerabilities - U.S. Department of Homeland Security - Strategic Principles For Securing The Internet Of Things and promote trust and transparency. Security should be readdressed (IoT) on an ongoing basis as the component in the supply chain is replaced, Information System - FTC - Internet of Things: Privacy & Security in a Connected World removed or upgraded. Security Governance & - U.S. Department of Health and Human Services Food and Drug Administration (FDA) Center for Risk Management Devices and Radiological Health - Postmarket Management of Cybersecurity in Medical Devices Risks and Threats Risk Assessment procedure should be initiated using a top‐down Guidance for Industry and Food and Drug Administration Staff Identification decomposition method that requires first answering three - Software Assurance Forum for Excellence in Code (SAFECode) - NPO - Call it the Internet of and Assessment fundamental questions: Connected Things: The IoT Security Conundrum - Where is the targeted application deployed (Legal constraints - Cloud Security Alliance (CSA) - Future-proofing the Connected World: 13 Steps to Developing and cultural significance) Secure IoT Products - For what purpose (Scope) - Cloud Security Alliance (CSA) - New Security Guidance for Early Adopters of the IoT - For which scenarios (Business requirements) - IoT Security Foundation (IoTSF)

text: - GSM Association (GSMA) - IoT Security Guidelines GP-PS-12: Identify the intended use and environment of a given IoT Information System - oneM2M - Standards for M2M and the Internet of Things device. This will help developers and manufacturers determine the Security Governance & - Internet Research Task force (IRTF) - State-of-the-Art and Challenges for the Internet of Things most suitable technical features for the IoT device’s operation, and Risk Management Security the security measures required. This will also help to effectively - International Telecommunication Union (ITU) - Unleashing the potential of the Internet of Things handle bugs or enhancement requests. IT Security Architecture - AT&T Cybersecurity Insights - Exploring IoT Security Volume 2

text: GP-TM-01: Employ a hardware-based immutable root of trust. The - U.S. Department of Homeland Security - Strategic Principles For Securing The Internet Of Things

text: Hardware Root of Trust is a trusted hardware component which IT Security Architecture (IoT)

text: Hardware receives control at power-on. It then extends the chain of trust to - Cloud Security Alliance (CSA) - Future-proofing the Connected World: 13 Steps to Developing

text: security other hardware, firmware, and software components. The Root of Physical and Secure IoT Products

text: Trust should then be attestable by software agents running within environmental security - EuroSMART (the voice of the Smart Security Industry) - Internet Of Trust Security And Privacy In

text: and throughout the infrastructure. The Connected World

text: GP-TM-02: Use hardware that incorporates security features to - IETF (Internet Engineering Task Force) - IETF RFC 7452 Architectural Considerations in Smart strengthen the protection and integrity of the device – for example, Object Networking specialised security chips / coprocessors that integrate security at the - ISACA - Performing a Security Risk Assessment transistor level, embedded in the processor, that provide: - IoT Security Foundation (IoTSF) - Chain of trust boot-loader which authenticates the operating - GSM Association (GSMA) - IoT Security Guidelines system before loading it - OpenFog Consortium - The 8 Pillars of the OpenFog Reference Architecture - Chain of trust operating system which authenticates application - International Electrotechnical Commission (IEC) - IEC White Paper on “IoT 2020: Smart and software before loading it secure IoT platform” - Hardware secure boot process and Locking Critical Sections of - Symantec - An Internet of Things Reference Architecture Memory - Microsoft - Cybersecurity Policy For The Internet Of Things - Protected memory (NVM/RAM/Cache) to avoid snooping and - Industrial Internet Consortium (IIC) reverse engineering IT Security Architecture - Encryption and anonymity - Random Number Generation (RNG) Physical and - Tamper detection environmental security - Environment monitoring and internal control - Trusted Execution Environment. Secure Code fetching & Execution (Integrity checks) - Code and data signatures, built during compilation and stored and verified during execution - A trusted storage of device identity and authentication means, including protection of keys at rest and in use - Protection against unprivileged accessing security sensitive code.

text: Protection against local and physical attacks can be covered via functional security. GP-TM-03: The boot process initialises the main hardware - ISO27001 #A12. Operations security components, and starts the operating system. Trust must be - NIST SP 800-30 established in the boot environment before any trust in any other IT Security Architecture - NIST SP 800-53 software or executable program can be claimed, so the booted - SA-13 Trustworthiness environment must be verified and determined to be in an - SI-7 Software, Firmware, And Information Integrity uncompromised state. Trust and - CM-11 User-Installed Software Integrity GP-TM-04: Sign code cryptographically to ensure it has not been - NIST SP 800-160 - F.1.18 Trusted Communication Channels Management tampered with after being signed as safe for the device, and - European Commission - Advancing the Internet of Things in Europe implement run-time protection and secure execution monitoring to - IERC European Research Cluster on the Internet of Things be sure malicious attacks do not overwrite code after it is loaded. IT Security Architecture - The President’s National Security Telecommunications Advisory Committee - NSTAC Report to Only run signed code and never unsigned code. Measuring the boot- the President on the Internet of Things process enables the detection of manipulation of the host OS and - IIC (Industrial Internet Consortium) - Industrial Internet of Things Volume G4: Security software, so that malicious changes in the behaviour of the devices Framework (IIC:PUB:G4:V1.0:PB:20160926)

text: can be detected. It enables boot-time detection of rootkits, viruses - Trusted Computing Group (TCG) - Guidance for Securing IoT Using TCG Technology Reference and worms. Document - IoT Security Foundation (IoTSF) - Symantec - An Internet of Things Reference Architecture - Infineon - Hardware Security for Smart Grid End Point Devices

text: GP-TM-05: Control the installation of software on operational systems, to prevent unauthenticated software and files being loaded Identity and access onto it. In the event that the product is intended to allow unmanagement authenticated software, such software should only be run with limited permissions and/or sandbox. Computer security incident management GP-TM-06: Restore Secure State - Enable a system to return to a state that was known to be secure, after a security breach has occured or if Continuity of an upgrade has not been successful. Operations

text: Crisis Management GP-TM-07: Use protocols and mechanisms able to represent and manage trust and trust relationships. Each communication channel Ecosystem must be trustworthy to a level commensurate with the security Management dependencies it supports (i.e., how much it is trusted by other components to perform its security functions).

text: GP-TM-08: Enable security by default. Any applicable security Information System - IERC European Research Cluster on the Internet of Things features should be enabled by default, and any unused or insecure Security Governance & - U.S. Department of Homeland Security - Strategic Principles For Securing The Internet Of Things functionalities should be disabled by default. Strong security controls Risk Management (IoT) should be something the consumer has to deliberately disable rather - U.S. Federal Communications Commission, Public Safety & Homeland Security Bureau Strong default than deliberately enable. IT Security Architecture -

text: Article 29

text: Data Protection Working Party - Opinion 8/2014 on the on Recent Developments on security and the Internet of Things privacy GP-TM-09: Establish hard to crack device individual default - Cloud Security Alliance (CSA) - Identity and Access Management for the Internet of Things passwords. Usernames and passwords for IoT devices supplied by the - IoT Security Foundation (IoTSF) Identity and access manufacturer are often never changed by the user and are easily - GSM Association (GSMA) - IoT Security Guidelines management cracked, and a hard to crack default password is still a weakness if it - HM Government - National cyber security strategy 2016-2021 is used for more than one device. - Symantec - Internet Security Threat Report (ISTR)

text: GP-TM-10: Personal data must be collected and processed fairly and Information System lawfully. The fairness principle specifically requires that personal data Security Governance & - ISO27001 #A18. Compliance should never be collected and processed without the data subject’s Risk Management - NIST SP 800-53 consent. - AC-21 Information Sharing GP-TM-11: Make sure that personal data is used for the specified Information System - AC-22 Publicly Accessible Content purposes for which they were collected, and that any further Security Governance & - AC-23 Data Mining Protection processing of personal data is compatible and that the data subjects Risk Management - OWASP I5. Internet of Things Top Ten are well informed. - Data Protection Directive

text: GP-TM-12: Minimise the data collected and retained. Many IoT - DG Commissioned Study - Definition of a Research and Innovation Policy Leveraging Cloud

text: stakeholders only need aggregated data and have no need of the raw Computing and IoT Combination

text: data collected by IoT devices. Stakeholders must delete raw data as Information System - ARTICLE 29 Data Protection Working Party - Opinion 8/2014 on the on Recent Developments on

text: soon as they have extracted the data required for their data Security Governance & the Internet of Things

text: Data protection processing. As a principle, deletion should take place at the nearest Risk Management - EC Alliance for Internet of Things Innovation (AIOTI)

text: and compliance point of data collection of raw data (e.g. on the same device after - U.S. Federal Communications Commission, Public Safety & Homeland Security Bureau

text: processing). - The President’s National Security Telecommunications Advisory Committee - NSTAC Report to

text: the President on the Internet of Things GP-TM-13: IoT stakeholders must be compliant with the EU General - Cloud Security Alliance (CSA) - Future-proofing the Connected World: 13 Steps to Developing Data Protection Regulation (GDPR). The complex mesh of Information System Secure IoT Products stakeholders involved asks for/implies the necessity of a precise Security Governance & - GSM Association (GSMA) - IoT Security Guidelines allocation of legal responsibilities among them with regard to the Risk Management - Online Trust Alliance (OTA) - IoT Trust Framework and Trust Framework Resource Guide processing of the individual’s personal data, based on the specificities - IETF (Internet Engineering Task Force) - IETF RFC 7452 Architectural Considerations in Smart of their respective interventions. Object Networking GP-TM-14: Users of IoT products and services must be able to - AIOTI. Digitisation of Industry Policy Recommendations exercise their rights to information, access, erasure, rectification, Information System - International Telecommunication Union (ITU) - Unleashing the potential of the Internet of Things data portability, restriction of processing, objection to processing, Security Governance & - Infineon - Hardware Security for Smart Grid End Point Devices and their right not to be evaluated on the basis of automated Risk Management

text: processing.

text: - ISO/IEC CD 30141 Internet of Things Reference Architecture (IoT RA) GP-TM-15: Design with system and operational disruption in mind. - NIST SP 800-53 - SI-13 Predictable Failure Prevention Build IoT devices to fail safely and securely, so that the failure does -

text: Article 29

text: Data Protection Working Party - Opinion 8/2014 on the on Recent Developments on not lead to a greater systemic disruption. Have a fail-safe design that the Internet of Things specifically ensures that no malfunction can impact the delivery of a Physical and - U.S. Department of Homeland Security - Strategic Principles For Securing The Internet Of Things commodity (e.g. energy, gas, heat or water), preventing the system environmental security (IoT) System safety from causing unacceptable risk of injury or physical damage, - IoT Security Foundation (IoTSF) and reliability protecting the environment against harm, and avoiding interruption - Atlantic Council (Brent Scowcroft Center On International Security) - Smart Homes and the of safety-critical processes. Internet of Things

text: - GSM Association (GSMA) - IoT Security Guidelines Computer security - BITAG (Broadband Internet Technical Advisory Group) - Internet of Things (IoT) Security and GP-TM-16: Mechanisms for self-diagnosis and self-repair/healing to incident management Privacy Recommendations Technical Working Group Report recover from failure, malfunction or a compromised state. - BSI (Bundesamt für Sicherheit in der Informationstechnik) - Protection Profile for the Gateway of

text: Continuity of a Smart Metering System (Smart Meter Gateway PP), Certification-ID: BSI-CC-PP-0073 Operations - International Electrotechnical Commission (IEC) - IEC White Paper on “IoT 2020: Smart and secure IoT platform” - International Telecommunication Union (ITU) - Unleashing the potential of the Internet of Things - I am the cavalry - Five Star Automotive Cyber Safety Framework GP-TM-17: Ensure standalone operation - essential features should - AT&T Cybersecurity Insights - Exploring IoT Security Volume 2 continue to work with a loss of communications and chronicle - Symantec - Internet Security Threat Report (ISTR) negative impacts from compromised devices or cloud-based systems. Continuity of A loss of communications shall not compromise the integrity of the Operations device, and IoT devices should continue to function if the cloud backend fails.

text: GP-TM-18: Ensure the device software/firmware, its configuration - ISO27001 A12. Operations security and its applications have the ability to update Over-The-Air (OTA), - NIST SP 800-53 - SI-7 Software, Firmware, And Information Integrity IT Security that the update server is secure, that the update file is transmitted - NIST Framework for Improving Critical Infrastructure Cybersecurity Administration via a secure connection, that it does not contain sensitive data (e.g. - OWASP I9. Internet of Things Top Ten hardcoded credentials), and that it is signed by an authorised trust - U.S. Department of Homeland Security - Strategic Principles For Securing The Internet Of Things Secure Software IT Security Architecture entity and encrypted using accepted encryption methods, and that (IoT) / Firmware the update package has its digital signature, signing certificate and -

text: Article 29

text: Data Protection Working Party - Opinion 8/2014 on the on Recent Developments on updates Identity and access signing certificate chain, verified by the device before the update the Internet of Things management process begins. - U.S. Federal Communications Commission, Public Safety & Homeland Security Bureau - NOI Fifth Generation Wireless Network and Device Security IT security maintenance Failing to build in OTA update capabilities will leave devices exposed U.S. Department of Commerce, National Telecommunications and Information Administration, to threats and vulnerabilities for the entirety of their lifetimes Internet Policy Task Force & Digital Economy Leadership Team - Fostering The Advancement Of

text: The Internet Of Things - Cloud Security Alliance (CSA) - Future-proofing the Connected World: 13 Steps to Developing Secure IoT Products - IoT Security Foundation (IoTSF) - GSM Association (GSMA) - IoT Security Guidelines - Atlantic Council (Brent Scowcroft Center On International Security) - Smart Homes and the Internet of Things GP-TM-19: Offer an automatic firmware update mechanism. Devices - Online Trust Alliance (OTA) - IoT Trust Framework and Trust Framework Resource Guide should be configured to check for the existence of firmware updates - BITAG (Broadband Internet Technical Advisory Group) - Internet of Things (IoT) Security and at frequent intervals. Automatic firmware updates should be enabled IT Security Architecture Privacy Recommendations Technical Working Group Report by default. A device may offer an option to disable automatic - ARMOUR (Large-Scale Experiments of IoT Security Trust) firmware updates and require authentication for it. - IIC (Industrial Internet Consortium) - Industrial Internet of Things Volume G4: Security Framework (IIC:PUB:G4:V1.0:PB:20160926, 173 pages) - IETF (Internet Engineering Task Force) - IETF RFC 7452 Architectural Considerations in Smart Object Networking - IETF (Internet Engineering Task Force) - Best Current Practices for Securing Internet of Things (IoT) Devices - Internet Research Task force (IRTF) - State-of-the-Art and Challenges for the Internet of Things Security - BSI (Bundesamt für Sicherheit in der Informationstechnik) - Community Draft SYS 4.4 on General IoT Device (Entwurf SYS.4.4: Allgemeines IoT-Gerät) - BSI (Bundesamt für Sicherheit in der Informationstechnik) - Protection Profile for the Gateway of a Smart Metering System (Smart Meter Gateway PP), Certification-ID: BSI-CC-PP-0073 GP-TM-20: Backward compatibility of firmware updates. Automatic - ISACA - Performing a Security Risk Assessment firmware updates should not change network protocol interfaces in - AIOTI. Digitisation of Industry Policy Recommendations any way that is incompatible with previous versions. Updates and - International Telecommunication Union (ITU) - Unleashing the potential of the Internet of Things IT Security Architecture patches should not modify user-configured preferences, security, - HM Government - National cyber security strategy 2016-2021 and/or privacy settings without user notification. Users should have - I am the cavalry - Five Star Automotive Cyber Safety Framework the ability to approve, authorise or reject updates. - AT&T Cybersecurity Insights - Exploring IoT Security Volume 2 - Symantec - An Internet of Things Reference Architecture - Symantec - Internet Security Threat Report (ISTR) - Microsoft - Cybersecurity Policy For The Internet Of Things - Infineon - Hardware Security for Smart Grid End Point Devices

text: - ISO27001 #A9. Access Control GP-TM-21: Design the authentication and authorisation schemes - NIST SP 800-30 (unique per device) based on the system-level threat models. Devices Identity and access Authentication - NIST SP 800-53 should include mechanisms to reliably authenticate their backend management - IA-5 Authenticator Management services and supporting applications. - AC-7 Unsuccessful Logon Attempts

text: - AC-14 Permitted Actions Without Identification Or Authentication

text: - NIST Framework for Improving Critical Infrastructure Cybersecurity GP-TM-22: Ensure default passwords and even default usernames are Identity and access - OWASP I1, I2, I6. Internet of Things Top Ten changed during the initial setup, and that weak, null or blank management - U.S. Federal Communications Commission, Public Safety & Homeland Security Bureau - FCC passwords are not allowed. White Paper, Cybersecurity Risk Reduction

text: - Cloud Security Alliance (CSA) - Identity and Access Management for the Internet of Things

text: - Cloud Security Alliance (CSA) - Future-proofing the Connected World: 13 Steps to Developing

text: Secure IoT Products GP-TM-23: Authentication mechanisms must use strong passwords or - Cloud Security Alliance (CSA) - New Security Guidance for Early Adopters of the IoT personal identification numbers (PINs), and should consider using Identity and access - IoT Security Foundation (IoTSF) two-factor authentication (2FA) or multi-factor authentication (MFA) management - GSM Association (GSMA) - IoT Security Guidelines like Smartphones, Biometrics, etc., and certificates. - oneM2M - Standards for M2M and the Internet of Things

text: - Online Trust Alliance (OTA) - IoT Trust Framework and Trust Framework Resource Guide

text: - EuroSMART (the voice of the Smart Security Industry) - Internet Of Trust Security And Privacy In

text: The Connected World GP-TM-24: Authentication credentials including but not limited to Identity and access - IETF (Internet Engineering Task Force) - IETF RFC 7452 Architectural Considerations in Smart user passwords shall be salted, hashed and/or encrypted. management Object Networking

text: - World Wide Web Consortium (W3C) - WoT Current Practices

text: - BSI (Bundesamt für Sicherheit in der Informationstechnik) - Community Draft SYS 4.4 on General GP-TM-25: Protect against ‘brute force’ and/or other abusive login Identity and access IoT Device (Entwurf SYS.4.4: Allgemeines IoT-Gerät) attempts (such as automated login bots, etc.) by locking or disabling management - ISACA - Performing a Security Risk Assessment user and device support account(s) after a reasonable number of - International Telecommunication Union (ITU) - Unleashing the potential of the Internet of Things invalid log in attempts, or y making the user wait a certain amount of IT Security - AT&T Cybersecurity Insights - Exploring IoT Security Volume 2 time to login again after a failed attempt. This protection should also Administration - Symantec - Internet Security Threat Report (ISTR) consider keys stored in devices. - Microsoft - Cybersecurity Policy For The Internet Of Things

text: - Infineon - Hardware Security for Smart Grid End Point Devices

text: GP-TM-26: Ensure password recovery or reset mechanism is robust Identity and access and does not supply an attacker with information indicating a valid management account. The same applies to key update and recovery mechanisms.

text: - ISO27001 #A9. Access Control - NIST SP 800-30 - NIST SP 800-53 - AC-6 Least Privilege GP-TM-27: Limit permissions of the allowed actions for a given - CA-6 Security Authorization system (e.g., the information owner or the database administrator - NIST Framework for Improving Critical Infrastructure Cybersecurity determines who can update a shared file accessed by a group of - OWASP I1, I2, I6. Internet of Things Top Ten online users). Implement fine-grained authorisation mechanisms - - FTC - Internet of Things: Privacy & Security in a Connected World Identity and access such as Attribute-Based Access Control (ABAC) or Role-Based Access - IOT-A (Internet of Things Architecture) management Control (RBAC)- for executing privileged actions, access to files and - Software Assurance Forum for Excellence in Code (SAFECode) - NPO - Call it the Internet of directories, applications, etc. Use the Principle of least privilege Connected Things: The IoT Security Conundrum (POLP): applications must operate at the lowest privilege level - Cloud Security Alliance (CSA) - New Security Guidance for Early Adopters of the IoT possible. - IoT Security Foundation (IoTSF)

text: - GSM Association (GSMA) - IoT Security Guidelines Authorisation - oneM2M - Standards for M2M and the Internet of Things - IETF (Internet Engineering Task Force) - IETF RFC 7452 Architectural Considerations in Smart Object Networking - IETF (Internet Engineering Task Force) - Best Current Practices for Securing Internet of Things (IoT) Devices - World Wide Web Consortium (W3C) - WoT Current Practices - BSI (Bundesamt für Sicherheit in der Informationstechnik) - Community Draft on Implementation GP-TM-28: Device firmware should be designed to isolate privileged Notes for the module SYS 4.4 on General IoT Device (Entwurf Umsetzungshinweise zum Baustein code, processes and data from portions of the firmware that do not SYS.4.4 Allgemeines IoT-Gerät) need access to them, and device hardware should provide isolation IT Security Architecture - International Electrotechnical Commission (IEC) - IEC White Paper on “IoT 2020: Smart and concepts to prevent unprivileged from accessing security sensitive secure IoT platform” code. in order to minimise the potential for compromised code to - ISACA - Performing a Security Risk Assessment access those code and/or data. - International Telecommunication Union (ITU) - Unleashing the potential of the Internet of Things - Industrial Internet Consortium (IIC)

text: GP-TM-29: Data integrity and confidentiality must be enforced by access controls. When the subject requesting access has been Information System - ISO27001 #A9. Access Control, #A11. Physical and Environmental security authorised to access particular processes, it is necessary to enforce Security Governance & - NIST SP 800-30 the defined security policy. The effectiveness and the strength of Risk Management - NIST SP 800-53 access control depend on the correctness of the access control - Physical And Environmental Protection Control Family (PE) decisions (e.g., how the security rules are configured) and the Identity and access - SA-18 Tamper Resistance And Detection strength of access control enforcement (e.g., the design of software management - AC-1 Access Control Policy And Procedures or hardware security). - NIST Framework for Improving Critical Infrastructure Cybersecurity - OWASP Access control - OWASP I10. Internet of Things Top Ten GP-TM-30: Ensure a context-based security and privacy that reflects Information System - European Commission - Advancing the Internet of Things in Europe different levels of importance (e.g. emergency crisis, home Security Governance & - IERC European Research Cluster on the Internet of Things automation). Risk Management - FTC - Internet of Things: Privacy & Security in a Connected World - oneM2M - Standards for M2M and the Internet of Things GP-TM-31: Since some devices, gateways, etc. are required to be - International Electrotechnical Commission (IEC) - IEC White Paper on “IoT 2020: Smart and managed remotely rather than operated manually in the field, secure IoT platform” Access Control - measures for tamper protection and detection are needed. Detection - Cloud Security Alliance (CSA) - Future-proofing the Connected World: 13 Steps to Developing Physical and and reaction to hardware tampering should not rely on network Secure IoT Products Environmental connectivity. Physical and - OTA IoT Trust Framework security environmental security - IoT Security Foundation (IoTSF) Hardware tampering means that an attacker has physical control of - GSM Association (GSMA) - IoT Security Guidelines the device for some period of time. Broadly speaking, hardware - Online Trust Alliance (OTA) - IoT Trust Framework and Trust Framework Resource Guide tampering might occur at any of the different periods in the life cycle - Trusted Computing Group (TCG) - Guidance for Securing IoT Using TCG Technology Reference of a device. Document - BSI (Bundesamt für Sicherheit in der Informationstechnik) - Community Draft on Implementation Notes for the module SYS 4.4 on General IoT Device (Entwurf Umsetzungshinweise zum Baustein GP-TM-32: Ensure that the device cannot be easily disassembled and SYS.4.4 Allgemeines IoT-Gerät) that the data storage medium is encrypted at rest and cannot be - BSI (Bundesamt für Sicherheit in der Informationstechnik) - Protection Profile for the Gateway of Physical and easily removed. There should be mechanisms to control device a Smart Metering System (Smart Meter Gateway PP), Certification-ID: BSI-CC-PP-0073 environmental security security settings, such as remotely locking or erasing contents of a - International Electrotechnical Commission (IEC) - IEC White Paper on “IoT 2020: Smart and device if the device has been stolen. secure IoT platform” - International Telecommunication Union (ITU) - Unleashing the potential of the Internet of Things - International Telecommunication Union (ITU) - Unleashing the potential of the Internet of Things GP-TM-33: Ensure that devices only feature the essential physical - Symantec - An Internet of Things Reference Architecture external ports (such as USB) necessary for them to function and that - Microsoft - Cybersecurity Policy For The Internet Of Things Physical and the test/debug modes are secure, so they cannot be used to environmental security maliciously access the devices. In general, lock down physical ports to only trusted connections.

text: - ISO27001 #A10. Cryptography GP-TM-34: Ensure a proper and effective use of cryptography to - ISO 27031 7.4.3 protect the confidentiality, authenticity and/or integrity of data and - NIST SP 800-30 information (including control messages), in transit and in rest. - NIST SP 800-53 - SC-13 Cryptographic Protection IT Security Architecture Ensure the proper selection of standard and strong encryption - NIST Framework for Improving Critical Infrastructure Cybersecurity algorithms and strong keys, and disable insecure protocols. Verify the - OWASP Guide to Cryptography robustness of the implementation. - U.S. Federal Communications Commission, Public Safety & Homeland Security Bureau - IOT-A (Internet of Things Architecture) - Software Assurance Forum for Excellence in Code (SAFECode) - NPO - Call it the Internet of Connected Things: The IoT Security Conundrum - Cloud Security Alliance (CSA) - Future-proofing the Connected World: 13 Steps to Developing Secure IoT Products GP-TM-35: Cryptographic keys must be securely managed. Encryption - IoT Security Foundation (IoTSF) is only as robust as the ability for any encryption based system to IT Security Architecture - GSM Association (GSMA) - IoT Security Guidelines keep the encryption key hidden. Cryptographic key management - oneM2M - Standards for M2M and the Internet of Things includes key generation, distribution, storage, and maintenance. - BITAG (Broadband Internet Technical Advisory Group) - Internet of Things (IoT) Security and Privacy Recommendations Technical Working Group Report - EuroSMART (the voice of the Smart Security Industry) - Internet Of Trust Security And Privacy In Cryptography The Connected World - IIC (Industrial Internet Consortium) - Industrial Internet of Things Volume G4: Security Framework (IIC:PUB:G4:V1.0:PB:20160926) GP-TM-36: Build devices to be compatible with lightweight - IETF (Internet Engineering Task Force) - IETF RFC 7452 Architectural Considerations in Smart encryption and security techniques (including entities secure identification, secure configuration, etc.) that can, on the one hand, Object Networking IT Security Architecture - IETF (Internet Engineering Task Force) - Best Current Practices for Securing Internet of Things be usable on resource-constrained devices, and, on the other hand, (IoT) Devices be scalable so to minimise the management effort and maximise their usability. - Trusted Computing Group (TCG) - Guidance for Securing IoT Using TCG Technology Reference Document - Internet Research Task force (IRTF) - State-of-the-Art and Challenges for the Internet of Things Security - BSI (Bundesamt für Sicherheit in der Informationstechnik) - Protection Profile for the Gateway of a Smart Metering System (Smart Meter Gateway PP), Certification-ID: BSI-CC-PP-0073 GP-TM-37: Support scalable key management schemes. It has to be - ISACA - Performing a Security Risk Assessment considered that tiny sensor nodes cannot provide all security features - AIOTI. Digitisation of Industry Policy Recommendations because they have lots of system limitations. Thus, the sensed data IT Security Architecture - International Telecommunication Union (ITU) - Unleashing the potential of the Internet of Things carried over infrastructure networks may not have strong encryption - AT&T Cybersecurity Insights - Exploring IoT Security Volume 2 or security protection. - Symantec - Internet Security Threat Report (ISTR) - Infineon - Hardware Security for Smart Grid End Point Devices

text: GP-TM-38: Guarantee the different security aspects -confidentiality

text: (privacy), integrity, availability and authenticity- of the information in

text: transit on the networks or stored in the IoT application or in the IT Security Architecture Cloud, using data encryption methods to minimise network threats - ISO27001 #A10. Cryptography such as replay, interception, packet sniffing, wiretapping, or - NIST SP 800-30 eavesdropping. - NIST SP 800-163

text: - NIST Framework for Improving Critical Infrastructure Cybersecurity

text: GP-TM-39: Ensure that communication security is provided using - OWASP I4. Internet of Things Top Ten

text: state-of-the-art, standardised security protocols, such as TLS for IT Security Architecture - FTC - Internet of Things: Privacy & Security in a Connected World

text: encryption. - U.S. Department of Homeland Security - Strategic Principles For Securing The Internet Of Things

text: (IoT)

text: - Cloud Security Alliance (CSA) - Future-proofing the Connected World: 13 Steps to Developing IT Security Architecture Secure IoT Products GP-TM-40: Ensure credentials are not exposed in internal or external - IoT Security Foundation (IoTSF) network traffic Identity and access - GSM Association (GSMA) - IoT Security Guidelines management - Online Trust Alliance (OTA) - IoT Trust Framework and Trust Framework Resource Guide

text: GP-TM-41: Guarantee data authenticity to enable trustable - BITAG (Broadband Internet Technical Advisory Group) - Internet of Things (IoT) Security and Secure and exchanges (from data emission to data reception - both ways). Data is Privacy Recommendations Technical Working Group Report trusted often stored, cached, and processed by several nodes; not just sent IT Security Architecture - IIC (Industrial Internet Consortium) - Industrial Internet of Things Volume G4: Security communications from point A to point B. For these reasons, data should always be Framework (IIC:PUB:G4:V1.0:PB:20160926)

text: signed whenever and wherever the data is captured and stored. - World Wide Web Consortium (W3C) - WoT Current Practices

text: - International Electrotechnical Commission (IEC) - IEC White Paper on “IoT 2020: Smart and GP-TM-42: Do not trust data received and always verify any secure IoT platform” interconnections. Discover, identify and verify/authenticate the devices connected to the network before trust can be established, - OpenFog Consortium - The 8 Pillars of the OpenFog Reference Architecture IT Security Architecture - Trusted Computing Group (TCG) - Guidance for Securing IoT Using TCG Technology Reference and preserve their integrity for trustable solutions and services. For Document example, a device measures its own integrity as part of boot, but Ecosystem - Internet Research Task force (IRTF) - State-of-the-Art and Challenges for the Internet of Things does not validate those measurements - when the device applies to Management Security join a network, part of joining involves sending an integrity report for - International Telecommunication Union (ITU) - Unleashing the potential of the Internet of Things remote validation. If validation fails, the end point is diverted to a remediation network for action. - AT&T Cybersecurity Insights - Exploring IoT Security Volume 2

text: - Symantec - An Internet of Things Reference Architecture GP-TM-43: IoT devices should be restrictive rather than permissive in - Symantec - Internet Security Threat Report (ISTR) communicating: When possible, devices should not be reachable via IT Security Architecture - Infineon - Hardware Security for Smart Grid End Point Devices inbound connections by default. IoT devices should not rely on the

text: network firewall alone to restrict communication, as some Ecosystem

text: communication between devices within the home may not traverse Management

text: the firewall.

text: GP-TM-44: Make intentional connections. Prevent unauthorised connections to it or other devices the product is connected to, at all levels of the protocols. IoT devices must provide notice and/or IT Security Architecture request a user confirmation when initially pairing, onboarding, and/or connecting with other devices, platforms or services.

text: GP-TM-45: Disable specific ports and/or network connections for selective connectivity. If necessary, provide users with guidelines to IT Security Architecture perform this process in the final implementation.

text: GP-TM-46: Rate limiting – controlling the traffic sent or received by a IT Security Architecture network to reduce the risk of automated attacks.

text: GP-TM-47: Risk Segmentation - Splitting network elements into - ISO27001 #A12. Operations security Information System - NIST SP 800-53 - SC-5 Denial Of Service Protection separate components to help isolate security breaches and minimise Security Governance & overall risk. Networks can be divided into isolated subnetworks to - NIST Framework for Improving Critical Infrastructure Cybersecurity Risk Management - OWASP I1, I3, I6. Internet of Things Top Ten boost performance and improve security. - FTC - Internet of Things: Privacy & Security in a Connected World - U.S. Federal Communications Commission, Public Safety & Homeland Security Bureau - NOI Fifth Generation Wireless Network and Device Security GP-TM-48: Protocols should be designed to ensure that, if a single IT Security Architecture - Software Assurance Forum for Excellence in Code (SAFECode) - NPO - Call it the Internet of device is compromised, it does not affect the whole set, since smart Connected Things: The IoT Security Conundrum objects are often deployed as sets of identical or almost identical Ecosystem - Cloud Security Alliance (CSA) - Future-proofing the Connected World: 13 Steps to Developing devices. Management Secure IoT Products Secure Interfaces - IoT Security Foundation (IoTSF) and network - GSM Association (GSMA) - IoT Security Guidelines services Ecosystem - Online Trust Alliance (OTA) - IoT Trust Framework and Trust Framework Resource Guide GP-TM-49: Avoid provisioning the same secret key in an entire Management - BITAG (Broadband Internet Technical Advisory Group) - Internet of Things (IoT) Security and product family, since compromising a single device would be enough Privacy Recommendations Technical Working Group Report to expose the rest of the product family. Identity and access - IIC (Industrial Internet Consortium) - Industrial Internet of Things Volume G4: Security management Framework (IIC:PUB:G4:V1.0:PB:20160926) - IETF (Internet Engineering Task Force) - IETF RFC 7452 Architectural Considerations in Smart GP-TM-50: Ensure only necessary ports are exposed and available. IT Security Architecture Object Networking GP-TM-51: Implement a DDoS-resistant and Load-Balancing - World Wide Web Consortium (W3C) - WoT Current Practices infrastructure to protect the services against DDoS attacks which can - International Electrotechnical Commission (IEC) - IEC White Paper on “IoT 2020: Smart and IT Security Architecture affect the device itself or other devices and/or users on the local secure IoT platform” network or other networks. - Symantec - Internet Security Threat Report (ISTR)

text: GP-TM-52: Ensure web interfaces fully encrypt the user session, from

text: the device to the backend services, and that they are not susceptible IT Security Architecture

text: to XSS, CSRF, SQL injection, etc.

text: GP-TM-53: Avoid security issues when designing error messages. An

text: error message should give/display only the concise information the IT Security user needs – it must not expose sensitive information that can be Administration exploited by an attacker, such as an error ID, the version of the web

text: server, etc.

text: - ISO27001 #A12. Operations security GP-TM-54: Data input validation (ensuring that data is safe prior to - NIST SP 800-53 - SI-10 Information Input Validation use) and output filtering. - NIST SP 800-183 - 2.5 Primitive #5 (16,19&20): Decision Trigger

text: - OWASP Secure Coding Practices - Input Validation Security is a concern for decision triggers (malware or general IT Security Architecture - Software Assurance Forum for Excellence in Code (SAFECode) - NPO - Call it the Internet of defects). Other possibilities here might be indirect manipulation of Secure input and Connected Things: The IoT Security Conundrum input values to the trigger by tampering with or restricting the input output handling IT Security - IoT Security Foundation (IoTSF) values. Reliability is a concern for decision triggers (general defects). Administration - GSM Association (GSMA) - IoT Security Guidelines Decision triggers could be inconsistent, self-contradictory, and - International Electrotechnical Commission (IEC) - IEC White Paper on “IoT 2020: Smart and incomplete. Understanding how bad data propagates to affect secure IoT platform” decision triggers is paramount. Failure to execute decision triggers at - ISACA - Performing a Security Risk Assessment time may have undesired consequences. - Symantec - An Internet of Things Reference Architecture

text: - ISO27001 #A12. Operations security - NIST SP 800-92 - NIST Framework for Improving Critical Infrastructure Cybersecurity - OWASP Logging Cheat Sheet - Software Assurance Forum for Excellence in Code (SAFECode) - NPO - Call it the Internet of Connected Things: The IoT Security Conundrum - Cloud Security Alliance (CSA) - Future-proofing the Connected World: 13 Steps to Developing Secure IoT Products - Cloud Security Alliance (CSA) - New Security Guidance for Early Adopters of the IoT GP-TM-55: Implement a logging system that records events relating - GSM Association (GSMA) - IoT Security Guidelines to user authentication, management of accounts and access rights, - IIC (Industrial Internet Consortium) - Industrial Internet of Things Volume G4: Security Logging modifications to security rules, and the functioning of the system. Detection Framework (IIC:PUB:G4:V1.0:PB:20160926) The logs must also be preserved on durable storage - Trusted Computing Group (TCG) - Guidance for Securing IoT Using TCG Technology Reference and retrievable via an authenticated connection. Document - BSI (Bundesamt für Sicherheit in der Informationstechnik) - Community Draft on Implementation Notes for the module SYS 4.4 on General IoT Device (Entwurf Umsetzungshinweise zum Baustein SYS.4.4 Allgemeines IoT-Gerät) - BSI (Bundesamt für Sicherheit in der Informationstechnik) - Protection Profile for the Gateway of a Smart Metering System (Smart Meter Gateway PP), Certification-ID: BSI-CC-PP-0073 - ISACA - Performing a Security Risk Assessment - I am the cavalry - Five Star Automotive Cyber Safety Framework - Symantec - An Internet of Things Reference Architecture - Microsoft - Cybersecurity Policy For The Internet Of Things

text: - ISO27001 #A12. Operations security - ISO 27031 8.1.2 - NIST SP 800-30 - NIST SP 800-53 - AU-1 Audit And Accountability Policy And Procedures Monitoring and GP-TM-56: Implement regular monitoring to verify the device Detection - SI-4 Information System Monitoring Auditing behaviour, to detect malware and to discover integrity errors. - CA-7 Continuous Monitoring - OWASP Error Handling, Auditing and Logging - FTC - Internet of Things: Privacy & Security in a Connected World - Software Assurance Forum for Excellence in Code (SAFECode) - NPO - Call it the Internet of Connected Things: The IoT Security Conundrum

text: - Cloud Security Alliance (CSA) - Future-proofing the Connected World: 13 Steps to Developing Secure IoT Products - Cloud Security Alliance (CSA) - New Security Guidance for Early Adopters of the IoT - GSM Association (GSMA) - IoT Security Guidelines - Online Trust Alliance (OTA) - IoT Trust Framework and Trust Framework Resource Guide - IIC (Industrial Internet Consortium) - Industrial Internet of Things Volume G4: Security GP-TM-57: The auditing of security-relevant events and the Framework (IIC:PUB:G4:V1.0:PB:20160926) Information System monitoring and tracking of system abnormalities are key elements in - BSI (Bundesamt für Sicherheit in der Informationstechnik) - Community Draft on Implementation Security Governance & the after-the-fact detection of, and recovery from, security breaches. Notes for the module SYS 4.4 on General IoT Device (Entwurf Umsetzungshinweise zum Baustein Risk Management Conduct periodic audits and reviews of security controls to ensure SYS.4.4 Allgemeines IoT-Gerät) that the controls are effective. Perform penetration tests at least - ISACA - Performing a Security Risk Assessment IT security maintenance biannually. - International Telecommunication Union (ITU) - Unleashing the potential of the Internet of Things - I am the cavalry - Five Star Automotive Cyber Safety Framework - Symantec - An Internet of Things Reference Architecture - Symantec - Internet Security Threat Report (ISTR) - Microsoft - Cybersecurity Policy For The Internet Of Things - Infineon - Hardware Security for Smart Grid End Point Devices

text: GP-OP-01: Develop an end-of-life strategy for IoT products. Security patches and updates will eventually be discontinued for some IoT devices. Therefore, developers should prepare and communicate a IT security maintenance product sunset plan from the initial stages to ensure that manufacturers and consumers are aware of the risks posed to a device beyond its expected expiry date. - U.S. Department of Homeland Security - Strategic Principles For Securing The Internet Of Things GP-OP-02: Disclose the duration and end-of-life security and patch (IoT) End-of-life support (beyond product warranty). Such disclosures should be - FTC - Internet of Things: Privacy & Security in a Connected World IT security maintenance support aligned to the expected lifespan of the device and communicated to - Online Trust Alliance (OTA) - IoT Trust Framework and Trust Framework Resource Guide the consumer prior to purchase. - BITAG (Broadband Internet Technical Advisory Group) - Internet of Things (IoT) Security and Privacy Recommendations Technical Working Group Report

text: GP-OP-03: Monitor the performance and patch known vulnerabilities up until the “end-of-support|” period of of a product’s lifecycle. Due to the limited life cycle of many IoT devices, critical, publicly known IT security maintenance security or privacy bugs will pose a risk to consumers using outdated devices.

text: GP-OP-04: Use proven solutions, i.e. well known communications - European Commission - ICT Standardisation Priorities for the Digital Single Market protocols and cryptographic algorithms, recognized by the scientific - European Commission - Advancing the Internet of Things in Europe community, etc. Certain proprietary solutions, such as custom - Software Assurance Forum for Excellence in Code (SAFECode) - NPO - Call it the Internet of cryptographic algorithms, should be avoided. Purely proprietary Connected Things: The IoT Security Conundrum approaches and standards limit interoperability and can severely - IIC (Industrial Internet Consortium) - Industrial Internet of Things Volume G4: Security Proven solutions IT Security Architecture hamper the potential of the Digital Single Market. Common open Framework (IIC:PUB:G4:V1.0:PB:20160926) standards will help users access new innovative services, especially - IETF (Internet Engineering Task Force) - Best Current Practices for Securing Internet of Things for SMEs, the public sector and the scientific community. In (IoT) Devices particular, the portability of applications and data between different - OASIS (Organization for the Advancement of Structured Information Standards) - Technical providers is essential to avoid lock-in. Committees

text: GP-OP-05: Establish procedures for analysing and handling security incidents. For any incident there should be a response to: a) confirm the nature and extent of the incident; b) take control of the situation; c) contain the incident; and IT security maintenance d) communicate with stakeholders - ISO27001 #A16. Information security incident management - ISO 27031 9.2 and 7.3 Establish management procedures in order to ensure a quick, - NIST SP 800-30 effective and orderly response to information security incidents. - NIST SP 800-53 - Incident Response Control Family (IR) - OWASP Top 10 Considerations For Incident Response GP-OP-06: Coordinated disclosure of vulnerabilities, including - U.S. Department of Health and Human Services Food and Drug Administration (FDA) Center for associated security practices to address identified vulnerabilities. A IT Security Architecture Devices and Radiological Health - Postmarket Management of Cybersecurity in Medical Devices Management of coordinated disclosure policy should involve developers, Guidance for Industry and Food and Drug Administration Staff security manufacturers, and service providers, and include information IT security maintenance '- U.S. Department of Homeland Security - STRATEGIC PRINCIPLES FOR SECURING THE INTERNET vulnerabilities regarding any vulnerabilities reported to a computer security incident of THINGS (IoT) and/or incidents response team (CSIRT). - Online Trust Alliance (OTA) - IoT Trust Framework and Trust Framework Resource Guide GP-OP-07: Participate in information sharing platforms to report - BITAG (Broadband Internet Technical Advisory Group) - Internet of Things (IoT) Security and IT security maintenance vulnerabilities and receive timely and critical information about Privacy Recommendations Technical Working Group Report current cyber threats and vulnerabilities from public and private - IETF (Internet Engineering Task Force) - Best Current Practices for Securing Internet of Things Computer security partners. Information sharing is a critical tool in ensuring (IoT) Devices incident management stakeholders are aware of threats as they arise. - Internet Research Task force (IRTF) - State-of-the-Art and Challenges for the Internet of Things Security GP-OP-08: Create a publicly disclosed mechanism for vulnerability IT security maintenance reports. Bug Bounty programs, for example, rely on crowdsourcing methods to identify vulnerabilities that companies’ own internal Computer security security teams may not catch. incident management

text: GP-OP-09: Ensure the personnel practices promote privacy and Information System security - train employees in good privacy and security practices for Security Governance & - ISO27001 #A7. Human Resource Security the secure usage of the systems, recognizing that technological Risk Management - NIST SP 800-30 expertise does not necessarily equate to security expertise. - NIST SP 800-50 Human Resource - NIST SP 800-53 - Awareness And Training Control Family (AT) Security Training Information System GP-OP-10: Document and monitor the privacy and security training - NIST Framework for Improving Critical Infrastructure Cybersecurity and Awareness Security Governance & activities. - FTC - Internet of Things: Privacy & Security in a Connected World Risk Management - U.S. Federal Communications Commission, Public Safety & Homeland Security Bureau - FCC GP-OP-11: Ensure that cybersecurity roles and responsibilities for all Information System White Paper, Cybersecurity Risk Reduction workforce are established and introduce personnel assignments in Security Governance & accordance with the specifics of the projects and security engineering Risk Management needs.

text: GP-OP-12: Data processed by a third-party (i.e., if the organisation

text: utilises a cloud email provider), must be protected by a data Information System

text: processing agreement with the third-party. With the transference of Security Governance &

text: data, the responsibility of protecting that data also should be Risk Management - ISO27001 #A18. Compliance

text: transferred and compliance verified. - NIST SP 800-53

text: - AC-20 Use Of External Information Systems GP-OP-13: Only share consumers’ personal data with third parties - PS-7 Third-Party Personnel Security

text: with consumers’ affirmative consent, unless required and limited for - NIST Framework for Improving Critical Infrastructure Cybersecurity Third-Party Information System the use of product features or service operation. Require that third- - OWASP Top 10 Privacy Risks Project - P7 Sharing of data with third party relationships Security Governance & party service providers are held to the same polices including holding - OWASP I5. Internet of Things Top Ten Risk Management such data in confidence and notification requirements of any data - Online Trust Alliance (OTA) - IoT Trust Framework and Trust Framework Resource Guide

text: loss/breach incident and/or unauthorised access. - Atlantic Council (Brent Scowcroft Center On International Security) - Smart Homes and the

text: Internet of Things

text: GP-OP-14: For IoT hardware manufacturers and IoT software - EY - Cybersecurity and the Internet of Things Information System developers it is necessary to adopt cyber supply chain risk Security Governance & management policies and to communicate cyber security Risk Management requirements to its suppliers and partners.

text: Annex B: Security measures and threats mapping

text: SECURITY MEASURES / GOOD PRACTICES THREAT GROUPS

text: GP-PS-01: Consider the security of the whole IoT system in a consistent and holistic approach during its whole lifecycle across all levels of device/application design and development, integrating security throughout the development,  Nefarious Activity /Abuse manufacture, and deployment GP-PS-02: Ensure the ability to integrate different security policies and techniques.  Nefarious Activity / Abuse GP-PS-03: Security must consider the risk posed to human safety  Nefarious Activity / Abuse Security by design GP-PS-04: Designing for power conservation should not compromise security  Nefarious Activity / Abuse GP-PS-05: Design architecture by compartments to encapsulate elements in case of attacks.  Nefarious Activity / Abuse GP-PS-06: For IoT hardware manufacturers and IoT software developers it is necessary to implement test plans to verify whether the product performs as it is expected. Penetration tests help to identify malformed input handling,  Nefarious Activity / Abuse authentication bypass attempts and overall security posture. GP-PS-07: For IoT software developers it is important to conduct code review during implementation as it helps to reduce  Nefarious Activity / Abuse bugs in a final version of a product.  Nefarious Activity / Abuse GP-PS-08: Make privacy an integral part of the system  Damage loss (IT assets) Privacy by design  Nefarious Activity / Abuse GP-PS-09: Perform privacy impact assessments before any new applications are launched  Damage loss (IT assets)  Nefarious Activity / Abuse GP-PS-10: Establish and maintain asset management procedures and configuration controls for key network and Asset Management  Damage loss (IT assets) information systems.  Eavesdropping / Interception / Hijacking  Outages GP-PS-11: Identify significant risks using a defence-in-depth approach  Nefarious Activity /Abuse Risks and Threats Identification  Eavesdropping / Interception / Hijacking and Assessment GP-PS-12: Identify the intended use and environment of a given IoT device  Failures / Malfunctions  Nefarious Activity  Physical attacks GP-TM-01: Employ a hardware-based immutable root of trust.  Disasters  Outages GP-TM-02: Use hardware that incorporates security features to strengthen the protection and integrity of the device - Hardware security specialized security chips / coprocessors that integrate security at the transistor level, embedded in the processor,  Physical attacks providing, among other things, a trusted storage of device identity and authentication means, protection of keys at rest  Disasters and in use, and preventing unprivileged from accessing to security sensitive code. Protection against local and physical  Outages attacks can be covered via functional security.

text: Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017 SECURITY MEASURES / GOOD PRACTICES THREAT GROUPS

text:  Failures / Malfunctions GP-TM-03: The boot process initializes the main hardware components, and starts the operating system. Trust must be  Nefarious Activity / Abuse established in the boot environment before any trust in any other software or executable program can be claimed.  Outages

text: GP-TM-04: Sign code cryptographically to ensure it has not been tampered after being signed as safe for the device, and  Nefarious Activity / Abuse implement run-time protection and secure execution monitoring to be sure malicious attacks do not overwrite code after  Eavesdropping / Interception / Hijacking it is loaded.  Outages Trust and Integrity Management GP-TM-05: Control the installation of software on operational systems, to prevent unauthenticated software and files  Nefarious Activity / Abuse being loaded onto it.  Eavesdropping / Interception / Hijacking  Outages GP-TM-06: Restore Secure State - Enable a system to return to a state that is known to be secure, after a security breach  Nefarious Activity / Abuse occurs or if an upgrade is not successful.  Eavesdropping / Interception / Hijacking

text:  Nefarious Activity / Abuse GP-TM-07: Use protocols and mechanisms able to represent and manage trust and trust relationships.  Eavesdropping / Interception / Hijacking

text:  Outages GP-TM-08: Enable security by default. Any applicable security features should be enabled by default, and any unused or  Nefarious Activity / Abuse insecure functionalities should be disabled by default. Strong default security and  Failures / Malfunctions privacy  Outages GP-TM-09: Establish hard to crack device individual default passwords.  Nefarious Activity / Abuse  Failures / Malfunctions

text: GP-TM-10: Personal data must be collected and processed fairly and lawfully. The fairness principle specifically requires  Damage / loss (IT Assets) that personal data should never be collected and processed without the user’s consent.  Nefarious Activity / Abuse

text: GP-TM-11: Make sure that personal data is used for the specified purposes for which they were collected, and that any  Damage / loss (IT Assets) further processing of personal data is compatible and that the data subjects are well informed.  Nefarious Activity / Abuse

text: Data protection and compliance GP-TM-12: Minimize the data collected and retained.  Damage / loss (IT Assets)

text:  Damage / loss (IT Assets) GP-TM-13: IoT stakeholders must be compliant with the EU General Data Protection Regulation (GDPR).  Nefarious Activity / Abuse

text: GP-TM-14: Users must be able to exercise their rights to information, access, erasure, rectification, data portability,  Damage / loss (IT Assets) restriction of processing, objection to processing, and their right not to be evaluated on the basis of automated  Nefarious Activity / Abuse processing.  Outages GP-TM-15: Design with system and operational disruption in mind, preventing the system from causing unacceptable risk  Failures / Malfunctions of injury or physical damage. System safety and reliability  Disasters

text: GP-TM-16: Mechanisms for self-diagnosis and self-repair/healing to recover from failure, malfunction or a compromised  Outages state.  Failures / Malfunctions

text: GP-TM-17: Ensure standalone operation - essential features should continue to work with a loss of communications and  Outages chronicle negative impacts from compromised devices or cloud-based systems.  Failures / Malfunctions

text: GP-TM-18: Ensure that the device software/firmware, its configuration and its applications have the ability to update  Outages Over-The-Air (OTA), that the update server is secure, that the update file is transmitted via a secure connection, that it  Failures / Malfunctions does not contain sensitive data (e.g. hardcoded credentials), and that it is signed by an authorised trust entity and  Nefarious Activity / Abuse encrypted using accepted encryption methods, and that the update package has its digital signature, signing certificate Secure Software / Firmware  Eavesdropping / Interception / Hijacking and signing certificate chain, verified by the device before the update process begins. updates  Outages GP-TM-19: Offer an automatic firmware update mechanism.  Failures / Malfunctions

text: GP-TM-20: Backward compatibility of firmware updates. Automatic firmware updates should not modify user-configured  Outages preferences, security, and/or privacy settings without user notification.  Failures / Malfunctions

text:  Failures / Malfunctions GP-TM-21: Design the authentication and authorization schemes (unique per device) based on the system-level threat  Nefarious Activity / Abuse models.  Eavesdropping / Interception / Hijacking  Failures / Malfunctions GP-TM-22: Ensure default passwords and even default usernames are changed during the initial setup, and that weak,  Nefarious Activity / Abuse null or blank passwords are not allowed.  Eavesdropping / Interception / Hijacking

text: GP-TM-23: Authentication mechanisms must use strong passwords or personal identification numbers (PINs), and should  Failures / Malfunctions consider using two-factor authentication (2FA) or multi-factor authentication (MFA) like Smartphones, Biometrics, etc.,  Nefarious Activity / Abuse and certificates.  Eavesdropping / Interception / Hijacking Authentication  Failures / Malfunctions GP-TM-24: Authentication credentials including but not limited to user passwords shall be salted, hashed and/or  Nefarious Activity / Abuse encrypted.  Eavesdropping / Interception / Hijacking  Failures / Malfunctions GP-TM-25: Protect against ‘brute force’ and/or other abusive login attempts. This protection should also consider keys  Nefarious Activity / Abuse stored in devices.  Eavesdropping / Interception / Hijacking  Failures / Malfunctions GP-TM-26: Ensure password recovery or reset mechanism is robust and does not supply an attacker with information  Nefarious Activity / Abuse indicating a valid account. The same applies to key update and recovery mechanisms.  Eavesdropping / Interception / Hijacking

text: GP-TM-27: Limit the permissions of actions allowed for a given system by Implementing fine-grained authorisation  Failures / Malfunctions mechanisms and using the Principle of least privilege (POLP): applications must operate at the lowest privilege level  Nefarious Activity / Abuse possible.  Eavesdropping / Interception / Hijacking Authorization GP-TM-28: Device firmware should be designed to isolate privileged code and data from portions of the firmware that do  Failures / Malfunctions not need access to them, and device hardware should provide isolation concepts to prevent unprivileged from accessing  Nefarious Activity / Abuse security sensitive code.  Eavesdropping / Interception / Hijacking

text:  Physical Attacks GP-TM-29: Data integrity and confidentiality must be enforced by access controls. When the subject requesting access  Failures / Malfunctions has been authorised to access particular processes, it is necessary to enforce the defined security policy.  Nefarious Activity / Abuse  Eavesdropping / Interception / Hijacking  Failures / Malfunctions  Nefarious Activity / Abuse GP-TM-30: Ensure a context-based security and privacy that reflects different levels of importance.  Eavesdropping / Interception / Hijacking Access Control - Physical and  Damage / Loss (IT Assets) Environmental security GP-TM-31: Measures for tamper protection and detection. Detection and reaction to hardware tampering should not rely  Physical attacks on network connectivity.  Nefarious Activity / Abuse GP-TM-32: Ensure that the device cannot be easily disassembled and that the data storage medium is encrypted at rest  Physical attacks and cannot be easily removed.  Nefarious Activity / Abuse GP-TM-33: Ensure that devices only feature the essential physical external ports (such as USB) necessary for them to  Physical attacks function and that the test/debug modes are secure, so they cannot be used to maliciously access the devices. In general,  Eavesdropping / Interception / Hijacking lock down physical ports to only trusted connections.  Failures / Malfunctions GP-TM-34: Ensure a proper and effective use of cryptography to protect the confidentiality, authenticity and/or integrity of data and information (including control messages), in transit and in rest. Ensure the proper selection of standard and  Nefarious Activity / Abuse strong encryption algorithms and strong keys, and disable insecure protocols. Verify the robustness of the  Eavesdropping / Interception / Hijacking implementation.  Nefarious Activity / Abuse GP-TM-35: Cryptographic keys must be securely managed. Cryptography  Eavesdropping / Interception / Hijacking  Nefarious Activity / Abuse GP-TM-36: Build devices to be compatible with lightweight encryption and security techniques.  Eavesdropping / Interception / Hijacking  Nefarious Activity / Abuse GP-TM-37: Support scalable key management schemes.  Eavesdropping / Interception / Hijacking  Failures / Malfunctions  Nefarious Activity / Abuse GP-TM-38: Guarantee the different security aspects -confidentiality (privacy), integrity, availability and authenticity- of  Eavesdropping / Interception / Hijacking the information in transit on the networks or stored in the IoT application or in the Cloud.  Failures / Malfunctions GP-TM-39: Ensure that communication security is provided using state-of-the-art, standardised security protocols, such as  Eavesdropping / Interception / Hijacking Secure and trusted TLS for encryption.  Damage / Loss (IT Assets) communications  Eavesdropping / Interception / Hijacking GP-TM-40: Ensure credentials are not exposed in internal or external network traffic.  Damage / Loss (IT Assets) GP-TM-41: Guarantee data authenticity to enable reliable exchanges from data emission to data reception. Data should  Nefarious Activity / Abuse always be signed whenever and wherever it is captured and stored.  Eavesdropping / Interception / Hijacking

text: GP-TM-42: Do not trust data received and always verify any interconnections. Discover, identify and verify/authenticate  Nefarious Activity / Abuse the devices connected to the network before trust can be established, and preserve their integrity for reliable solutions  Eavesdropping / Interception / Hijacking and services.  Failures / Malfunctions / Outages

text:  Nefarious Activity / Abuse GP-TM-43: IoT devices should be restrictive rather than permissive in communicating.  Eavesdropping / Interception / Hijacking

text: GP-TM-44: Make intentional connections. Prevent unauthorised connections to it or other devices the product is  Nefarious Activity / Abuse connected to, at all levels of the protocols.  Eavesdropping / Interception / Hijacking

text:  Nefarious Activity / Abuse GP-TM-45: Disable specific ports and/or network connections for selective connectivity.  Eavesdropping / Interception / Hijacking

text:  Nefarious Activity / Abuse GP-TM-46: Rate limiting – controlling the traffic sent or received by a network to reduce the risk of automated attacks.  Eavesdropping / Interception / Hijacking

text: GP-TM-47: Risk Segmentation. Splitting network elements into separate components to help isolate security breaches and  Eavesdropping / Interception / Hijacking minimise the overall risk.

text: GP-TM-48: Protocols should be designed to ensure that, if a single device is compromised, it does not affect the whole  Eavesdropping / Interception / Hijacking set.

text: GP-TM-49: Avoid provisioning the same secret key in an entire product family, since compromising a single device would  Eavesdropping / Interception / Hijacking be enough to expose the rest of the product family. Secure Interfaces and network  Eavesdropping / Interception / Hijacking services GP-TM-50: Ensure only necessary ports are exposed and available.  Failures / Malfunctions

text: GP-TM-51: Implement a DDoS-resistant and Load-Balancing infrastructure.  Nefarious Activity / Abuse

text: GP-TM-52: Ensure web interfaces fully encrypt the user session, from the device to the backend services, and that they  Nefarious Activity / Abuse are not susceptible to XSS, CSRF, SQL injection, etc.

text: GP-TM-53: Avoid security issues when designing error messages.  Nefarious Activity / Abuse

text: Secure input and output  Nefarious Activity / Abuse GP-TM-54: Data input validation (ensuring that data is safe prior to use) and output filtering. handling  Failures / Malfunctions

text: GP-TM-55: Implement a logging system that records events relating to user authentication, management of accounts and Logging  Damage / Loss (IT Assets) access rights, modifications to security rules, and the functioning of the system.

text: GP-TM-56: Implement regular monitoring to verify the device behaviour, to detect malware and to discover integrity  Damage / Loss (IT Assets) errors. Monitoring and Auditing GP-TM-57: Conduct periodic audits and reviews of security controls to ensure that the controls are effective. Perform  Damage / Loss (IT Assets) penetration tests at least biannually.  Nefarious Activity / Abuse

text: GP-OP-01: Develop an end-of-life strategy for IoT products.  Failures / Malfunctions End-of-life support GP-OP-02: Disclose the duration and end-of-life security and patch support (beyond product warranty).  Failures / Malfunctions

text:  Damage / Loss (IT Assets) GP-OP-03: Monitor the performance and patch known vulnerabilities for as long as possible during a product’s lifecycle.  Nefarious Activity / Abuse  Failures / Malfunctions GP-OP-04: Use proven solutions, i.e. well known communications protocols and cryptographic algorithms, recognized by  Damage / Loss (IT Assets) Proven solutions the scientific community, etc. Certain proprietary solutions, such as custom cryptographic algorithms, should be avoided.  Nefarious Activity / Abuse

text:  Failures / Malfunctions GP-OP-05: Establish procedures for analysing and handling security incidents.  Damage / Loss (IT Assets)

text:  Failures / Malfunctions  Damage / Loss (IT Assets) Management of security GP-OP-06: Coordinated disclosure of vulnerabilities.  Nefarious Activity / Abuse vulnerabilities and/or incidents  Eavesdropping / Interception / Hijacking  Outages

text: GP-OP-07: Participate in information sharing platforms to report vulnerabilities and receive timely and critical information  Damage / Loss (IT Assets) about current cyber threats and vulnerabilities from public and private partners. GP-OP-08: Create a publicly disclosed mechanism for vulnerability reports, e.g. Bug Bounty programs.  Damage / Loss (IT Assets)

text: GP-OP-09: Ensure the personnel practices promote privacy and security – train employees in good privacy and security  Nefarious Activity / Abuse practices. Human Resource Security GP-OP-10: Document and monitor the privacy and security training activities.  Nefarious Activity / Abuse Training and Awareness GP-OP-11: Ensure that cybersecurity roles and responsibilities for all workforce are established and introduce personnel  Nefarious Activity / Abuse assignments in accordance with the specifics of the projects and security engineering needs. GP-OP-12: Data processed by a third-party must be protected by a data processing agreement.  Failures / Malfunctions

text: GP-OP-13: Only share consumers’ personal data with third parties with consumers’ affirmative consent, unless required  Failures / Malfunctions and limited for the use of product features or service operation.  Damage / Loss (IT Assets) Third-Party relationships  Failures / Malfunctions  Damage / Loss (IT Assets) GP-OP-14: For IoT hardware manufacturers and IoT software developers it is necessary to adopt cyber supply chain risk  Nefarious Activity / Abuse management policies and to communicate cyber security requirements to its suppliers and partners.  Eavesdropping / Interception / Hijacking  Outages

text: Annex C: Security standards and references reviewed

text: This annex lists all the security standards, good practices guides and resources and their corresponding references that have been analysed to develop all of the security measures/good practices listed in chapter 4 and detailed in Annex A. The following table lists said resources, including the ones provided and/or pointed out by the experts interviewed. AUTHOR TITLE REFERENCE 1. EU Initiatives

text: DG CONNECT commissioned Definition of a Research and Innovation https://ec.europa.eu/digital-single-market/en/news/definition-research-and-innovation-policy-leveraging-cloudstudy, authored by IDC Italia S.r.L Policy Leveraging Cloud Computing and computing-and-iot-combination and TXT e-solutions S.p.A. IoT Combination Digitising European Industry Reaping the https://ec.europa.eu/digital-single-market/en/digitising-european-industry full benefits of a Digital Single Market http://eur-lex.europa.eu/legal-content/EN/TXT/?qid=1447773803386&uri=CELEX:52015DC0192 (COM(2016) 180 final) http://ec.europa.eu/newsroom/dae/document.cfm?doc_id=41205 Building A European Data Economy http://ec.europa.eu/newsroom/dae/document.cfm?doc_id=41247 https://ec.europa.eu/digital-single-market/en/news/communication-ict-standardisation-priorities-digital-single- European Commission ICT Standardisation Priorities for the market Digital Single Market http://ec.europa.eu/newsroom/dae/document.cfm?doc_id=15265 Advancing the Internet of Things in http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52016SC0110 Europe H2020 https://ec.europa.eu/programmes/horizon2020/ http://ec.europa.eu/information_society/newsroom/image/document/2017- EU cybersecurity initiatives 3/factsheet_cybersecurity_update_january_2017_41543.pdf

text: Article 29

text: Data Protection Working Opinion 8/2014 on the on Recent http://ec.europa.eu/justice/data-protection/article-29/documentation/opinion- Party Developments on the Internet of Things recommendation/files/2014/wp223_en.pdf IERC European Research Cluster IoT Governance, Privacy and Security http://www.internet-of-thingson the Internet of Things Issues - IERC Position Paper research.eu/pdf/IERC_Position_Paper_IoT_Governance_Privacy_Security_Final.pdf

text: AIOTI WG04: Report on Policy Issues https://aioti-space.org/wp-content/uploads/2017/03/AIOTIWG04Report2015-Policy-Issues.pdf EC Alliance for Internet of Things AIOTI WG03: SmartM2M; IoT Standards Innovation (AIOTI) landscape and future evolutions https://aioti-space.org/wp-content/uploads/2017/03/tr_103375v010101p-Standards-landscape-and-future- (October 2016 with the contribution of evolutions.pdf ETSI)

text: Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017 AUTHOR TITLE REFERENCE

text: AIOTI WG03: High Level Architecture https://aioti-space.org/wp-content/uploads/2017/03/AIOTI-WG3-IoT-High-Level-Architecture-Release_2_1.pdf (September 2016) AIOTI Digitisation of Industry Policy https://aioti-space.org/wp-content/uploads/2017/03/AIOTI-Digitisation-of-Ind-policy-doc-Nov-2016.pdf Recommendations AIOTI WG07 Report on Wearables https://aioti-space.org/wp-content/uploads/2017/03/AIOTIWG07Report2015-Wearables.pdf

text: AIOTI WG09 Report on Smart Mobility https://aioti-space.org/wp-content/uploads/2017/03/AIOTIWG09Report2015-Smart-Mobility.pdf

text: BEREC (Body of European BEREC Report on Enabling the Internet of http://berec.europa.eu/eng/document_register/subject_matter/berec/reports/5755-berec-report-on-enabling- Regulators for Electronic Things -

text: BoR (16) 39

text: the-internet-of-things Communications)

text: Cyber Security and Resilience of smart https://www.enisa.europa.eu/publications/cyber-security-and-resilience-of-smart-cars cars Security and Resilience of Smart Home https://www.enisa.europa.eu/publications/security-resilience-good-practices Environments Securing Smart Airports https://www.enisa.europa.eu/publications/securing-smart-airports Cyber security and resilience for Smart https://www.enisa.europa.eu/publications/cyber-security-and-resilience-for-smart-hospitals Hospitals IoT and Smart Infrastructure efforts https://www.enisa.europa.eu/iot/ ENISA Ad-hoc & sensor networking for m2m communications - Threat Landscape and https://www.enisa.europa.eu/publications/m2m-communications-threat-landscape good practices guide Threat Landscape and Good Practice https://www.enisa.europa.eu/publications/sdn-threat-landscape Guide for Software Defined Networks/5G

text: ENISA Programming Document https://www.enisa.europa.eu/publications/corporate/enisa-programming-document-2017-2019

text: Communication network dependencies https://www.enisa.europa.eu/publications/ics-scada-dependencies for ICS/SCADA Systems

text: 2. US Government Initiatives

text: NIST.SP.800-27 http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-27.pdf NIST.SP.800-30 http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf National Institute of Standards NIST.SP.800-50 http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-50.pdf and Technology (NIST) NIST.SP.800-53 http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-53.pdf NIST.SP.800-92 http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-92.pdf

text: NIST.SP.800-160 http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-160.pdf

text: NIST SP 800-183 - Network of ‘Things’ http://dx.doi.org/10.6028/NIST.SP.800-183

text: Framework for Improving Critical https://www.nist.gov/document-3766 Infrastructure Cybersecurity

text: NISTIR 7628 Revision 1 - Guidelines for http://nvlpubs.nist.gov/nistpubs/ir/2014/NIST.IR.7628r1.pdf Smart Grid Cyber Security

text: CPS PWG Cyber-Physical Systems (CPS) https://pages.nist.gov/cpspwg/ Framework

text: Securing the Internet of Things https://www.dhs.gov/securingtheIoT

text: U.S. Department of Homeland Security (DHS) Strategic Principles For Securing The https://www.dhs.gov/sites/default/files/publications/Strategic_Principles_for_Securing_the_Internet_of_Things-

text: Internet Of Things (IoT) 2016-1115-FINAL_v2-dg11.pdf

text: The President’s National Security NSTAC Report to the President on the Telecommunications Advisory http://www.dhs.gov/sites/default/files/publications/IoT Final Draft Report 11-2014.pdf Internet of Things Committee

text: U.S. Commission On Enhancing Report On Securing And Growing The https://www.nist.gov/document/cybersecurity-commission-report-final-postpdf National Cybersecurity Digital Economy

text: U.S. Department Of Commerce,

text: National Telecommunications And Fostering The Advancement Of The Information Administration, https://www.ntia.doc.gov/files/ntia/publications/iot_green_paper_01122017.pdf Internet Of Things Internet Policy Task Force & Digital

text: Economy Leadership Team

text: FCC White Paper, Cybersecurity Risk U.S. Federal Communications https://apps.fcc.gov/edocs_public/attachmatch/DOC-343096A1.pdf Reduction Commission, Public Safety & NOI Fifth Generation Wireless Network Homeland Security Bureau http://transition.fcc.gov/Daily_Releases/Daily_Business/2016/db1216/DA-16-1282A1.pdf and Device Security

text: U.S. Department of Health and

text: Human Services Postmarket Management of

text: Food and Drug Administration Cybersecurity in Medical Devices http://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/ucm4820

text: (FDA) Guidance for Industry and Food and Drug 22.pdf

text: Center for Devices and Administration Staff

text: Radiological Health

text: U.S. Federal Communications Internet of Things, Privacy and Security in https://www.ftc.gov/system/files/documents/reports/federal-trade-commission-staff-report-november-2013- Commission, Public Safety & a Connected World, FTC Staff report workshop-entitled-internet-things-privacy/150127iotrpt.pdf Homeland Security Bureau

text: Careful Connections: Building Security in https://www.ftc.gov/system/files/documents/plain-language/pdf0199-carefulconnections-

text: the Internet of Things buildingsecurityinternetofthings.pdf

text: Internet Of Things Enhanced United States Government Assessments and Guidance Are Needed https://www.gao.gov/assets/690/686203.pdf Accountability Office to Address Security Risks in DOD

text: IoT Security Upgradability and Patching -

text: National Telecommunications and Existing Standards, Tools and Initiatives https://www.ntia.doc.gov/files/ntia/publications/iotsecuritystandardscatalog.pdf Information Administration (NTIA) Working Group (WG1) Catalog of Existing

text: IoT Security Standards Version 0.01

text: 3. EU-funded projects

text: FI-WARE (Future Internet Core http://cordis.europa.eu/project/rcn/99929_en.html FI-WARE (Future Internet Core Platform) Platform) https://www.fiware.org/

text: IOT-A (Internet of Things http://cordis.europa.eu/project/rcn/95713_en.html IOT-A (Internet of Things Architecture) Architecture) http://www.meet-iot.eu/iot-a-deliverables.html

text: Agile-IoT (Adaptive Gateways for Agile-IoT (Adaptive Gateways for dIverse http://cordis.europa.eu/project/rcn/199853_en.html

text: dIverse muLtiple Environments) muLtiple Environments) http://agile-iot.eu/

text: Eye-O-T (Cyber security system Eye-O-T (Cyber security system with a with a high IoT network visibility high IoT network visibility and fast http://cordis.europa.eu/project/rcn/205793_en.html and fast vulnerability detection for vulnerability detection for Smart Homes) Smart Homes)

text: SCR (Disruptive Cybersecurity SaaS SCR (Disruptive Cybersecurity SaaS for for SMEs and freelance http://cordis.europa.eu/project/rcn/205788_en.html SMEs and freelance developers) developers)

text: TAMPRES (TAMper Resistant TAMPRES (TAMper Resistant Sensor http://cordis.europa.eu/project/rcn/95511_en.html

text: Sensor node) node) http://www.tampres.eu/

text: BUTLER (uBiquitous, secUre BUTLER (uBiquitous, secUre inTernet-of-

text: inTernet-of-things with Location things with Location and contExt- http://cordis.europa.eu/project/rcn/101349_en.html

text: and contExt-awaReness) awaReness)

text: ALMANAC (Reliable Smart Secure http://cordis.europa.eu/project/rcn/109709_en.html ALMANAC (Reliable Smart Secure Internet Of Things For Smart Internet Of Things For Smart Cities) http://www.almanac-project.eu/news.php Cities)

text: RERUM (REliable, Resilient and http://cordis.europa.eu/project/rcn/109710_en.html RERUM (REliable, Resilient and secUre secUre IoT for sMart city IoT for sMart city applications) https://ict-rerum.eu/ applications)

text: INSTET (Integral Security Trust INSTET (Integral Security Trust Element http://cordis.europa.eu/project/rcn/207692_en.html Element for the Internet of Things) for the Internet of Things)

text: BASTION (Leveraging Binary BASTION (Leveraging Binary Analysis to Analysis to Secure the Internet of http://cordis.europa.eu/project/rcn/193687_en.html Secure the Internet of Things) Things) ANASTACIA (Advanced Networked http://cordis.europa.eu/project/rcn/207199_en.html ANASTACIA Agents for Security and Trust Assessment http://www.anastacia-h2020.eu in CPS/IOT Architectures) ARMOUR (Large-Scale ARMOUR (Large-Scale Experiments of IoT http://cordis.europa.eu/project/rcn/199076_en.html Experiments of IoT Security Trust) Security Trust) http://www.armour-project.eu/

text: AdvIOT (Advanced Methods for AdvIOT (Advanced Methods for http://cordis.europa.eu/project/rcn/109385_en.html Analyzing and Improving the Analyzing and Improving the Reliability Reliability and Security of Novel and Security of Novel Environmentalhttp://www.adviot.eu/ Environmental-friendly Wireless friendly Wireless Devices for Internet of Devices for Internet of Things) Things)

text: 4. International Organizations/Alliances

text: OWASP Internet of Things Project https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project Open Web Application Security OWASP (Draft) IoT Security Guidance https://www.owasp.org/index.php/IoT_Security_Guidance Project (OWASP) IoT Top Ten 2014 Top Ten https://www.owasp.org/images/7/71/Internet_of_Things_Top_Ten_2014-OWASP.pdf

text: https://github.com/opengeospatial/sensorthings Open Geospatial Consortium OGC SensorThings API (former SWE for http://www.ogcnetwork.net/IoT (OGC) Standard Working Group IoT) http://docs.opengeospatial.org/is/15-078r6/15-078r6.html (SWG) on SensorThings https://portal.opengeospatial.org/files/15-078r6 International Telecommunication http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=y.2060 Union (ITU) ITU-T Y.4000/Y.2060 Overview of the http://www.itu.int/en/ITU-T/gsi/iot/Pages/default.aspx Global Standards Initiative on Internet of Things Internet of Things (IoT-GSI) – http://www.itu.int/en/ITU-T/studygroups/2013-2016/20/Pages/default.aspx concluded 07/2015 and superseded by Study Group Update of IoT and SC&C Standards http://www.itu.int/en/ITU-T/jca/iot/Documents/deliverables/Free-download-IoT-roadmap.doc 20 on IoT & its applications incl. Roadmap smart cities & communities Unleashing the potential of the Internet https://www.itu.int/en/publications/Documents/tsb/2016-InternetOfThings/index.html Joint Coordination Activity on of Things Internet of Things and Smart Cities and Communities (JCA-IoT and ITU-T SG20 http://www.itu.int/en/ITU-T/studygroups/2013-2016/20/Pages/default.aspx SC&C) Call it the Internet of Connected Things: http://www.safecode.org/call-it-the-internet-of-connected-things-the-iot-security-conundrum/ The IoT Security Conundrum

text: Software Assurance Forum for Excellence in Code (SAFECode) - http://www.safecode.org/wp-content/uploads/2014/09/SAFECode_Dev_Practices0211.pdf NPO

text: Future-proofing the Connected World: 13 Steps to Developing Secure IoT https://cloudsecurityalliance.org/download/future-proofing-the-connected-world/ Products

text: Cloud Security Alliance (CSA) Identity and Access Management for the https://cloudsecurityalliance.org/download/identity-and-access-management-for-the-iot/ Internet of Things

text: New Security Guidance for Early https://cloudsecurityalliance.org/download/new-security-guidance-for-early-adopters-of-the-iot/ Adopters of the IoT

text: IoT Security Compliance Framework https://iotsecurityfoundation.org/wp-content/uploads/2016/12/IoT-Security-Compliance-Framework.pdf

text: Connected Consumer Best Practice https://iotsecurityfoundation.org/wp-content/uploads/2016/12/Connected-Consumer-Products.pdf Guidelines IoT Security Foundation (IoTSF) Vulnerability Disclosure Best Practice https://iotsecurityfoundation.org/wp-content/uploads/2017/01/Vulnerability-Disclosure.pdf Guidelines

text: https://iotsecurityfoundation.org/wp-content/uploads/2015/09/IoTSF-Establishing-Principles-for-IoT-Security- Establishing Principles for IoT Security Download.pdf

text: Supporting the IoT http://www.etsi.org/technologies-clusters/technologies/internet-of-things

text: ETSI TR 103 375 SmartM2M; IoT Standards landscape and future http://www.etsi.org/deliver/etsi_tr/103300_103399/103375/01.01.01_60/tr_103375v010101p.pdf evolutions European Telecommunications Standards Institute (ETSI) ETSI TR 103 376 SmartM2M; IoT LSP use cases and http://www.etsi.org/deliver/etsi_tr/103300_103399/103376/01.01.01_60/tr_103376v010101p.pdf Specialist Task Force 505: standards gaps

text: IoT Standards landscaping and IoT ETSI TR 103 118 Machine-to-Machine European Large Scale Pilots (LSP) communications (M2M) http://www.etsi.org/deliver/etsi_tr/103100_103199/103118/01.01.01_60/tr_103118v010101p.pdf gap analysis Smart Energy Infrastructures security

text: ETSI TR 103 167 Machine-to-Machine http://www.etsi.org/deliver/etsi_tr/103100_103199/103167/01.01.01_60/tr_103167v010101p.pdf Communications (M2M)

text: ETSI TS 103 267 SmartM2M http://www.etsi.org/deliver/etsi_ts/103200_103299/103267/01.01.01_60/ts_103267v010101p.pdf

text: IoT Security Guidelines - Overview http://www.gsma.com/connectedliving/wp-content/uploads/2016/11/CLP.11-v1.1.pdf Document GSM Association (GSMA) IoT Security Guidelines for Service http://www.gsma.com/connectedliving/wp-content/uploads/2016/11/CLP.12-v1.1.pdf Ecosystems

text: IoT Security Guidelines for Endpoint http://www.gsma.com/connectedliving/wp-content/uploads/2016/11/CLP.13-v1.1.pdf Ecosystems IoT Security Guidelines for Network http://www.gsma.com/connectedliving/wp-content/uploads/2016/11/CLP.14-v1.1.pdf Operators https://www.gsma.com/iot/wp- IoT Security Self-Assessment Process content/uploads/2016/09/cl_iot_security_self_assessment_checklist__processes_05_17-1.zip GSMA Embedded SIM Remote http://www.gsma.com/connectedliving/wp-content/uploads/2014/01/1.-GSMA-Embedded-SIM-Remote- Provisioning Architecture Provisioning-Architecture-Version-1.1.pdf GSMA Remote Provisioning Architecture for Embedded UICC Technical http://www.gsma.com/newsroom/wp-content/uploads/SGP.02_v3.1.pdf Specification GSMA SAS Standard for Subscription http://www.gsma.com/aboutus/wp-content/uploads/2015/01/FS08-SAS_SM-Standard-v2_0.pdf Manager Roles GSMA SAS Methodology for Subscription http://www.gsma.com/connectedliving/wp-content/uploads/2014/10/SGP-09-GSMA-SAS-Methodology-for- Manager Roles Subscription-Manager-Roles.pdf

text: GSMA Remote Provisioning Architecture http://www.gsma.com/newsroom/wpfor Embedded UICC Test Specification content/uploads/SGP11_Remote_Provisioning_Architecture_for_Embedded_UICC_Test_Specification_v2_0.pdf

text: http://www.gsma.com/iot/gsma-iot-security-guidelines-complete-document-set/ GSMA IoT Security Guidelines https://www.gsma.com/iot/future-iot-networks/iot-security-guidelines/ IEEE Internet of Things http://iot.ieee.org/ IEEE Standards Association - IoT http://standards.ieee.org/innovate/iot/study.html Ecosystem Study Institute of Electrical and Internet Of Things Related Standards http://standards.ieee.org/innovate/iot/stds.html Electronics Engineers (IEEE) How to Build a Safer Internet of Things http://spectrum.ieee.org/telecom/security/how-to-build-a-safer-internet-of-things Standard for an Architectural Framework https://standards.ieee.org/develop/project/2413.html for the Internet of Things (IoT) http://otalliance.actonsoftware.com/acton/attachment/6361/f-008d/1/-/-/-/-/IoT Trust Framework.pdf OTA IoT Trust Framework and Trust Framework Resource Guide http://otalliance.actonsoftware.com/acton/attachment/6361/f-008e/1/-/-/-/-/IoT Framework Resource Online Trust Alliance (OTA) Guide.pdf

text: IoT Security & Privacy Trust Framework https://otalliance.org/system/files/files/initiative/documents/iot_trust_framework6-22.pdf v2.5

text: oneM2M Release 2 specifications http://www.onem2m.org/technical/published-documents

text: Technical Specification http://www.onem2m.org/images/files/deliverables/Release2/TR-0008-Security-V2_0_0.pdf

text: http://www.onem2m.org/images/files/deliverables/Release2/TR-0012-End-to-End- Technical Report - TR-0008 Security_and_Group_Authentication_V2_0_0.pdf oneM2M - Standards for M2M Technical Report - TR-0012 http://www.onem2m.org/images/files/deliverables/Release2/TS-0003_Security_Solutions-v2_4_1.pdf and the Internet of Things http://www.onem2m.org/images/files/deliverables/Release2/TR-0016- Technical Report - TR-0016 Authorization_Architecture_and_Access_Control_Policy-V2_0_0.pdf

text: Technical Report - TR-0019 http://www.onem2m.org/images/files/deliverables/Release2/TR-0019-Dynamic_Authorization-V2_0_0.pdf

text: Atlantic Council (Brent Scowcroft Smart Homes and the Internet of Things http://www.atlanticcouncil.org/publications/issue-briefs/smart-homes-and-the-internet-of-things Center On International Security) (issue brief)

text: Internet of Things (IoT) Security and BITAG (Broadband Internet Privacy Recommendations Technical https://www.bitag.org/report-internet-of-things-security-privacy-recommendations.php Technical Advisory Group) Working Group Report

text: EuroSMART (the voice of the Internet Of Trust Security And Privacy In http://www.eurosmart.com/news-publications/99-policy-papers/245-eurosmart-internet-of-trust-security-and-

text: Smart Security Industry) The Connected World privacy-in-the-connected-world.html

text: ICIT (Institute for Critical Rise of the Machines: The Dyn Attack http://icitech.org/icit-publication-the-rise-of-the-machines-the-dyn-attack-was-just-a-practice-run/ Infrastructure Technology) Was Just a Practice Run

text: Industrial Internet of Things Volume G4: IIC (Industrial Internet Security Framework http://www.iiconsortium.org/IISF.htm Consortium) (IIC:PUB:G4:V1.0:PB:20160926)

text: Internet of Things Security Guideline IoT-A (IoT Alliance) http://www.iot.org.au/s/IoTAA-Security-Guideline-V10-8242.pdf IoT Reference Architecture

text: IETF RFC 7452 Architectural

text: Considerations in Smart Object https://tools.ietf.org/html/rfc7452

text: Internet Research Task force (IRTF) Networking

text: Best Current Practices for Securing https://tools.ietf.org/pdf/draft-moore-iot-security-bcp-00.pdf Internet of Things (IoT) Devices

text: State-of-the-Art and Challenges for the https://tools.ietf.org/pdf/draft-irtf-t2trg-iot-seccons-04.pdf Internet of Things Security Internet Research Task force (IRTF) Secure IoT Bootstrapping: A Survey https://tools.ietf.org/pdf/draft-sarikaya-t2trg-sbootstrapping-03.pdf

text: Thing to Thing Research Group Survey on Thing Secure Bootstrapping https://tools.ietf.org/pdf/draft-liu-t2trg-bootstrapping-survey-00.pdf

text: (T2TRG) IoT architecture based on Virtual thing https://tools.ietf.org/pdf/draft-yang-t2trg-virtualthing-00.pdf environment for security

text: The Open Trust Protocol (OTrP) https://www.ietf.org/id/draft-pei-opentrustprotocol-04.txt

text: State-of-the-Art and Challenges for the https://tools.ietf.org/html/draft-irtf-t2trg-iot-seccons-04 Internet of Things Security

text: Best Current Practices for Securing https://datatracker.ietf.org/doc/draft-moore-iot-security-bcp/ Internet of Things (IoT) Devices

text: The Internet Engineering Task Force https://www.ietf.org/proceedings/56/ Internet Engineering Task Force (IETF®)56

text: (IETF) RFC 7925 https://tools.ietf.org/html/rfc7925

text: Datagram Transport Layer Security https://tools.ietf.org/html/rfc6347 Version 1.2

text: The Constrained Application Protocol https://tools.ietf.org/html/rfc7252 (CoAP)

text: IAB (Internet Architecture Board) IAB Workshop on IoT Software Updates https://www.iab.org/activities/workshops/iotsu/

text: World Wide Web Consortium Web of Things (WoT) Architecture http://w3c.github.io/wot/architecture/wot-architecture.html

text: (W3C) WoT Current Practices http://w3c.github.io/wot/current-practices/wot-practices.html

text: Guidance for Securing IoT Using TCG Trusted Computing Group (TCG) https://trustedcomputinggroup.org/guidance-securing-iot-using-tcg-technology-reference-document/ Technology Reference Document

text: OpenFog Reference Architecture https://www.openfogconsortium.org/wp-content/uploads/OpenFog-Reference-Architecture-Executive-

text: for Fog Computing Summary.pdf OpenFog Consortium The 8 Pillars of the OpenFog Reference https://www.openfogconsortium.org/wp-content/uploads/OpenFog-Pillars-10-page-summary.pdf Architecture

text: https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=mqtt OASIS (Organization for the

text: Advancement of Structured Technical Committees https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=amqp

text: Information Standards) https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=obix

text: http://www.openmobilealliance.org/release/DM/V1_3-20160524-A/OMA-TS-DM_Security-V1_3-20160524- Open Mobile Alliance for a OMA Device Management Security A.pdf Connected World (OMA) OMA LightweightM2M V1.0 http://www.openmobilealliance.org/release/LightweightM2M/V1_0-20170208-A/

text: Community Draft SYS 4.4 on General IoT https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/IT-Grundschutz- Device (Entwurf SYS.4.4: Allgemeines BSI (Bundesamt für Sicherheit in Modernisierung/BS_IoT.html?nn=7712584 IoT-Gerät) der Informationstechnik) Community Draft on Implementation

text: Notes for the module SYS 4.4 on General BMWi (Bundesministerium für https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/IT-Grundschutz- IoT Device (Entwurf Umsetzungshinweise Wirtschaft und Energie) Modernisierung/UH_IoT.html?nn=7712584 zum Baustein SYS.4.4 Allgemeines IoT-

text: Gerät)

text: Protection Profile for the Gateway of a Smart Metering System (Smart Meter https://www.commoncriteriaportal.org/files/ppfiles/pp0073b_pdf.pdf Gateway PP), Certification-ID: BSI-CC-PP- 0073 IPSO Security, Privacy & Identity (SPI) http://www.ipso-alliance.org/wp-content/uploads/2015/12/IPSO_SPI-Charter.pdf Working Group Charter IP for Smart Objects (IPSO) Enabling IoT Devices’ Hardware and Alliance Software Interoperability (IPSO Alliance http://www.ipso-alliance.org/wp-content/uploads/2016/11/2016-11-08_IPSO_Overview.pdf Technical Overview) Open Connectivity Foundation (formerly OIC-Open Interconnect OIC Security Specification v1.1.1 https://openconnectivity.org/specs/OIC_Security_Specification_v1.1.1.pdf Consortium) IEC White Paper on “IoT 2020: Smart and http://www.iec.ch/whitepaper/pdf/iecWP-loT2020-LR.pdf secure IoT platform” International Electrotechnical IEC/TR 62443-2-3, “Security for industrial Commission (IEC) automation and control systems - Part 2https://webstore.iec.ch/publication/22811 3: Patch management in the IACS environment.”

text: 5. Other references

text: ISO 27001 https://www.iso.org/standard/54534.html

text: ISO 27002 https://www.iso.org/standard/54533.html

text: ISO 27031 https://www.iso.org/standard/44374.html

text: https://www.iso.org/committee/45306.html International Organization for ISO/IEC JTC 1 SC 27 and SC41 https://www.iso.org/committee/6483279.html Standardization (ISO) ISO/IEC CD 30141 https://www.iso.org/standard/65695.html

text: ISO/IEC 15408 series https://www.iso.org/standard/50341.html

text: Internet of Things Reference http://isotc.iso.org/livelink/livelink/open/jtc1wg10 Architecture (IoT RA) https://www.w3.org/WoT/IG/wiki/images/9/9a/10N0536_CD_text_of_ISO_IEC_30141.pdf

text: Performing a Security Risk Assessment https://www.isaca.org/journal/archives/2010/volume-1/pages/performing-a-security-risk-assessment1.aspx ISACA IoT Journal Vol.3 https://www.isaca.org/Journal/archives/2017/Volume-3/Pages/default.aspx An Internet of Things Reference https://www.symantec.com/content/dam/symantec/docs/white-papers/iot-security-reference-architecture- Symantec Architecture en.pdf

text: https://www.symantec.com/security-center/threat-report Internet Security Threat Report (ISTR) Volume 22 https://resource.elq.symantec.com/LP=3980?cid=70138000001BjppAAC&mc=202671&ot=wp&tt=sw&inid=symc _threat-report_regular_to_leadgen_form_LP-3980_ISTR22-report-main Data-Over-Cable Service Interface CableLabs Specifications DOCSIS® 3.1 Security https://apps.cablelabs.com/specification/CM-SP-SECv3.1 Specification RISE SICS How to secure the Internet of Things? https://www.sics.se/sites/default/files/pub/lund-hannestschofenig_final.pdf National cyber security strategy 2016- https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/567242/national_cyber_securi HM Government 2021 ty_strategy_2016.pdf AT&T Cybersecurity Insights Exploring IoT Security Volume 2 https://www.business.att.com/cybersecurity/docs/exploringiotsecurity.pdf Five Star Automotive Cyber Safety https://www.iamthecavalry.org/wp-content/uploads/2014/08/Five-Star-Automotive-Cyber-Safety-February- I am the cavalry Framework 2015.pdf Microsoft - Cybersecurity Policy Cybersecurity Policy For The Internet Of https://mscorpmedia.azureedge.net/mscorpmedia/2017/05/IoT_WhitePaper_5_15_17.pdf For The Internet Of Things Things Hardware Security for Smart Grid End Infineon https://www.nrel.gov/esif/assets/pdfs/hardware_security_smart_grid.pdf Point Devices Industrial Automation and Control http://isa99.isa.org/ISA99%20Wiki/Home.aspx International Society of System Security Automation (ISA) IEC 62443: Industrial Network And https://www.isa.org/pdfs/autowest/phinneydone/ System Security Object Management Group DDS-Security http://www.omg.org/spec/DDS-SECURITY/1.0/

text: Thread Group Thread 1.1 Specification http://threadgroup.org/ThreadSpec Cloud Standards Customer Council Cloud Customer Architecture for IoT http://www.cloud-council.org/deliverables/cloud-customer-architecture-for-iot.htm (CSCC) https://industrie4.0.gtai.de/INDUSTRIE40/Navigation/EN/Topics/The-internet-of-things/internet-of-things-what- The Internet Of Things – What Is It? is-it.html https://industrie4.0.gtai.de/INDUSTRIE40/Navigation/EN/Topics/The-internet-of-things/embedded-systems-and- Embedded Systems And Networks networks.html Industrie 4.0 Digital Infrastructure https://industrie4.0.gtai.de/INDUSTRIE40/Navigation/EN/Topics/Smart-service-world/digital-infrastructure.html

text: https://industrie4.0.gtai.de/INDUSTRIE40/Navigation/EN/Topics/Smart-service-world/disruptive-business- Disruptive Business Models models.html Industrie 4.0 – What Is It? https://industrie4.0.gtai.de/INDUSTRIE40/Navigation/EN/Topics/Industrie-40/what-is-it.html North American Electric Reliability State of Reliability 2017 http://www.nerc.com/pa/rapa/pa/performance%20analysis%20dl/sor_2017_master_20170613.pdf Corp.

text: Broadband Forum User Services Platform (TR-369) https://broadbandforum.github.io/usp/ OAuth OAuth 2.0 https://oauth.net/ OPC Foundation Unified Architecture https://opcfoundation.org/about/opc-technologies/opc-ua/ Bruce Schneier Schneier on Security https://www.schneier.com/blog/archives/2017/02/security_and_pr.html Smart Grid Interoperability Panel Case studies and use cases http://www.sgip.org/case-studies-and-use-cases/ (SGIP) The Internet of Things (IoT) http://industries.ul.com/blog/the-internet-of-things-iot Underwriters Laboratories (UL) UL Cybersecurity Assurance Program http://industries.ul.com/cybersecurity LTE to 5G: Cellular and Broadband 3rd Generation Partnership Innovation - Internet of Things poised for http://www.3gpp.org/technologies/presentations-white-papers Project (3GPP) massive adoption with new Cellular IoT capabilities in 3GPP Release 13 The Digital Standard The Digital Standard http://thedigitalstandard.org/

text: Internet of Things Consortium Internet of Things Consortium http://iofthings.org/ Philips pushes lightbulb firmware update http://boingboing.net/2015/12/14/philips-pushes-lightbulb-firmw.html that locks out third-party bulbs Other Industrial Internet Consortium Develops https://securityintelligence.com/news/industrial-internet-consortium-develops-iot-security-framework/ an IoT Security Framework IoT Security Resources http://blog.mobilephonesecurity.org/2016/11/iot-security-resources.html

text: Annex D: Description of indicative IoT security incidents

text: SECURITY INCIDENT DATE DESCRIPTION At some point in 2009, the Puerto Rican Electric Power Authority (PREPA) suffered a series of power theft incidents related to its smart meter Puerto Rican Smart Meters 2009 deployment. The attack required physical access to the smart meters, and hacked it is believed that former employees of the meter manufacturer were altering the smart meters to reduce power bills . On April 11, 2013, a vulnerability in Foscam wireless cameras was disclosed by security researchers in a presentation titled “To watch or to Foscam IP baby-cam be watched: Turning your surveillance camera against you”. Later, on August 10, 2013 hijacked August 10, an attacker gained control of one of those cameras in Houston, Texas, which was being used as a baby-cam. The attacker was able to see, hear and speak through the camera . The intrusion into Target’s systems was traced back to network credentials stolen from a third-party IoT HVAC vendor. It is believed that Target allowed that HVAC vendor remote access to its network in order to report fluctuations in store temperature which might November 15 - Target data breach have affected how long a customer stayed within a given store. December 15, 2013 Nevertheless, it remains a mystery why the point of sale system was not segmented from the rest of the Target network . The intrusion took place on November 15, 2013, and one month later, the data breach had already resulted in the theft of 40 million credit and debit card accounts . A security vulnerability in BMW’s Connected Drive system allowed researchers to unlock the vehicles affected without the car keys. The attack took advantage of a feature that allows drivers who have been locked out of their vehicles to request the remote unlocking of their car from a BMW assistance line. The researchers were able to impersonate BMW’s Connected Drive January 2015 BMW servers and send, over the public cellular network, remote vulnerable (demonstration) 85 unlocking instructions to vehicles . The software patch for the 2.2 million cars equipped with Connected Drive adds HTTPS encryption to the connection from BMW to the car and ensures that the car only accepts connections from a server with the correct security certificate . Charlie Miller and Chris Valasek developed a zero-day exploit that targets Jeep Cherokees, giving an attacker, who may be miles away, complete Jeep car remotely hijacked July 21, 2015 control -via the Internet- of thousands of vulnerable vehicles. The attack (demonstration) is performed by sending commands through the Jeep’s entertainment system to its dashboard functions, steering, brakes, and transmission .

text: See https://www.metering.com/puerto-rico-smart-meters-believed-to-have-been-hacked-and-such-hacks-likely-to-spread/ 82 See https://www.forbes.com/sites/kashmirhill/2013/08/13/how-a-creep-hacked-a-baby-monitor-to-say-lewd-things-to-a-2-year-old/ 83 See https://www.mocana.com/blog/2014/02/05/iot-hack-connected-target-breach See http://krebsonsecurity.com/2014/02/target-hackers-broke-in-via-hvac-company/ AJ Trainor, Amalia Safer, Lily Houghton, «BMW ConnectedDrive Vulnerability». See https://www.cs.bu.edu/~goldbe/teaching/HW55815/presos/bmw.pdf See https://www.mocana.com/blog/2014/02/05/iot-hack-connected-target-breach 87 See https://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/

text: Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017 SECURITY INCIDENT DATE DESCRIPTION Security researchers Runa Sandvik and Michael Auger have developed a set of techniques that could allow an attacker to exploit vulnerabilities in TrackingPoint‘s smart the software of a US$13,000 TrackingPoint self-aiming rifle via its Wi-Fi sniper rifle hack July 29, 2015 connection. (demonstration) The attacker could then compromise the scope’s targeting system, preventing the gun from firing or even causing it to miss the intended target, hitting another one . A cyber-attack on digital toymaker VTech Holdings exposed the data of 6.4 million children and 4.9 million adults. The personal information VTech Toymaker data stolen was not encrypted, and it included names, email addresses, November 8, 2015 breach passwords, secret questions and answers for password retrieval, IP addresses, postal addresses, download histories, chat logs, and children’s names, photos, genders and birth dates . Mirai gathered a botnet made up of more than one million hacked IoT devices, mostly DVRs and CCTV cameras, which were infected through their Telnet port. Mirai - DDoS on OVH September 19, 2016 The French hosting company OVH is believed to be the first to have hosting provider suffered a DDoS attack coming from the Mirai botnet, which was reported to have peaked at 1 Tbps, one of the largest recorded in history in terms of volume . Just a day after the attack against OVH, the Mirai botnet conducts a DDoS Mirai - DDoS on “Krebs on September 20, 2016 attack on “Krebs on Security” website that surpassed 620 Gbps of traffic, Security” website 90 making it also one of the largest recorded in history in terms of volume . Hajime is a “vigilante” spreading IoT worm that, like Mirai, takes advantage of devices with default usernames and passwords to gain control over them, via their Telnet ports. Its purpose is believed to be fighting the Mirai botnet for control over IoT products – once a device is infected, Hajime blocks access to ports 23 (Telnet), 7547, 5555, and 5358, Hajime October 15, 2016 which are common entry points for the rival Mirai worm and other threats . At the moment, the Hajime worm is not doing anything malign – it just displays the following message: “Just a white hat, securing some systems” . Some of Mirai’s targets were cloud-related services, such as DNS provider Mirai - DDoS on Dyn DNS Dyn, which suffered a DDoS attack that affected several high-profile October 21, 2016 provider websites, including Amazon, Netflix, PayPal and Spotify. Unconfirmed reports say the peak of the attack reached around 1.2 Tbps . In Finland, a DDoS Attack took down the heating systems of at least two DDoS on building blocks’ November 3, 2016 housing blocks in the city of Lappeenranta, leaving their residents without central heating system 94 heating in sub-zero temperatures for more than a week .

text: 88 See https://www.wired.com/2015/07/hackers-can-disable-sniper-rifleor-change-target/ 89 See http://www.cnbc.com/2015/12/02/vtech-hack-data-of-64m-kids-exposed.html See https://www.symantec.com/content/dam/symantec/docs/reports/istr-22-2017-en.pdf See https://blog.radware.com/security/2017/04/hajime-futureproof-botnet/ 92 See https://www.symantec.com/connect/blogs/hajime-worm-battles-mirai-control-internet-things See https://dyn.com/blog/dyn-analysis-summary-of-friday-october-21-attack/ 94 See http://thehackernews.com/2016/11/heating-system-hacked.html

text: Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017 SECURITY INCIDENT DATE DESCRIPTION Mirai - DDoS on Deutsche Mirai botnet targets Deutsche Telekom routers, affecting more than November 27, 2016 95 Telekom network 900,000 customers . Cloudpets is a company that sells Internet-connected teddy bears, allowing kids to communicate with their far-away parents. Cloudpets Cloudpets’ DB held for December 25, 2016 - customers’ data were left for two weeks in a publicly available database ransom January 8, 2017 without password or firewall protection. More than 820,000 customer credentials were exposed, as well as two million message recordings. In addition, the database was also held for ransom . The Romantik Seehotel Jägerwirt, a 4-star hotel in the Austrian Alps, had its digital key system breached and held for ransom. The attackers managed to take down the entire key system – the guests could no longer get into their hotel rooms and new key cards could not be programmed. Romantik Seehotel January 25, 2017 The hotel has admitted they had to pay a ransom worth thousands of Jägerwirt Bitcoin to the cybercriminals, who restored the key system and the computers as soon as they received the payment. The attackers left a backdoor in the system to exploit it in the near future, but when they tried again, the hotel had already bolstered its security . Apart from Cloudpets’ customer database being completely insecure, it turns out Cloudpets’ teddy bears were themselves insecure too. CloudPets' toys did not use any standard Bluetooth security features, such as pairing encryption with their owner's smartphone app, so anyone within range (10 meters with a normal smartphone) could just connect to it and send and receive commands and data – e.g. uploading a message Cloudpets and “Meine to the toy, or silently triggering the toy's recording functionality and later February 17 - 27, Freundin Cayla” - insecure downloading the audio the toy has recorded. In other words, the teddy 2017 Bluetooth bears could be turned into remote surveillance devices, used to harass toddlers like some insecure baby monitors have in the past, such as the Foscam IP baby-cam case . Just one week before, the German government banned the Internetconnected “Meine Freundin Cayla” doll for the same reasons that concern Cloudpets’ toys – it had vulnerabilities that could be exploited by an attacker to remotely spy on children . BrickerBot is a bot that permanently incapacitates –Permanent DoS (PDoS)– poorly secured IoT devices, leaving them in a “bricked” state BrickerBot March 20, 2017 before they can be conscripted into Internet-crippling denial-of-service armies. The latest version BrickerBot.3 appeared April 20, one month 100,101 after BrickerBot.1 first surfaced .

text: 95 See https://www.engadget.com/2016/11/29/mirai-botnet-targets-deutsche-telekom-routers-in-global-cyberatt/ 96 See https://motherboard.vice.com/en_us/article/internet-of-things-teddy-bear-leaked-2-million-parent-and-kids-message-recordings 97 See https://www.thelocal.at/20170128/hotel-ransomed-by-hackers-as-guests-locked-in-rooms 98 See https://motherboard.vice.com/en_us/article/how-this-internet-of-things-teddy-bear-can-be-remotely-turned-into-a-spy-device 99 See https://www.bundesnetzagentur.de/SharedDocs/Pressemitteilungen/DE/2017/14012017_cayla.html See https://arstechnica.com/security/2017/04/brickerbot-the-permanent-denial-of-service-botnet-is-back-with-a-vengeance/ See https://ics-cert.us-cert.gov/alerts/ICS-ALERT-17-102-01A

text: ENISA

text: Athens Office

text: 1 Vasilissis Sofias & Meg. Alexandrou Marousi 151 24, Athens, Greece TP-05-17-148-EN-N PO Box 1309, 710 01 Heraklion, Greece ISBN: 978-92-9204-236-3 DOI: 10.2824/03228 Tel: +30 28 14 40 9710 info@enisa.europa.eu www.enisa.europa.eu