Good Practices for Security of IoT - Secure Software Development Lifecycle

GOOD PRACTICES FOR SECURITY OF IOT Secure Software Development Lifecycle NOVEMBER 2019

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

ABOUT ENISA

The European Union Agency for Cybersecurity (ENISA) has been working to make Europe cyber secure since 2004. ENISA works with the EU, its member states, the private sector and Europe’s citizens 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 crossborder communities committed to improving network and information security throughout the EU. Since 2019, it has been drawing up cybersecurity certification schemes. More information about ENISA and its work can be found at www.enisa.europa.eu. CONTACT For contacting the authors please use iot-security@enisa.europa.eu For media enquiries about this paper, please use press@enisa.europa.eu AUTHORS ENISA ACKNOWLEDGEMENTS Alessandro Cosenza Bticino S.p.A Arndt Kohler IBM Benedikt Abendroth Microsoft Corporation Carlos Valderrama Geomantis Corporation Limited Alex Cruz Farmer Cloudflare Cédric Lévy-Bencheton Cetome Eric Vetillard NXP Filip Chytry Avast Hannes Tschofenig ARM Ltd. Hagai Bar-El ARM Ltd. Ian Smith GSM Association (GSMA) Antonio Jara HOP Ubiquitous S.L. (HOPU) Julio Hernandez-Castro University of Kent Mirko Ross asvin.io Mark Harrison Pentestpartners Sylvie Wuidart STMicroelectronics Tiago Da Costa Silva Cisco Jeff Schutt Cisco Evangelos Gazis Huawei Technologies Co., Ltd. Viacheslav Zolotnikov Kaspersky Ekaterina Rudina Kaspersky Wolfgang Klasen Siemens AG Pierre Kobes Siemens AG Yun Shen Symantec Adrien Becue Airbus Dharminder Debisarun Palo Alto Networks Denis Justinek Biokoda Ernie Hayden Jacobs Georges-Henri Leclercq Engie Gisele Widdershoven Accenture Jalal Bouhdada Applied Risk Jens Mehrfeld BSI Konstantin Rogalas Honeywell 1 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

Pascal Oser CERN Pirmin Heinzer Reporting and Analysis Centre for Information Assurance MELANI Rafal Leszczyna Gdansk University of Technology Roberto Minicucci BHGE Samuel Linares iHackLabs Stefano Zanero Politecnico di Milano Victor Fidalgo Villar INCIBE (The Spanish National Cybersecurity Institute) Vytautas Butrimas NATO Energy Security Center of Excellence Roger Jardí-Cedó Nestlé S.A. Aaron Guzman OWASP Maor Vermucht VDOO Tommy Ross BSA José Alejandro Rivas Vidal Applus+ Laboratories Dirk-Willem van Gulik Web Weaving LEGAL NOTICE Notice must be taken that this publication represents the views and interpretations of ENISA, unless stated otherwise. This publication should not be construed to be a legal action of ENISA or the ENISA bodies unless adopted pursuant to the Regulation (EU) No 2019/881. 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 Cybersecurity (ENISA), 2019 Reproduction is authorised provided the source is acknowledged. ENISA owns the copyright for the images on the cover and within the report. For any use or reproduction of photos or other material that is not under the ENISA copyright, permission must be sought directly from the copyright holders. ISBN 978-92-9204-316-2, DOI: 10.2824/742784 2 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

TABLE OF CONTENTS

1. INTRODUCTION 7 1.1 OBJECTIVES 8 1.2 SCOPE 8 1.3 TARGET AUDIENCE 8 1.4 METHODOLOGY 8 1.5 STRUCTURE OF THE DOCUMENT 10 2. IOT SECURE SDLC 11 2.1 REQUIREMENTS 12 2.2 SOFTWARE DESIGN 13 2.3 DEVELOPMENT/IMPLEMENTATION 15 2.4 TESTING AND ACCEPTANCE 16 2.5 DEPLOYMENT AND INTEGRATION 17 2.6 MAINTENANCE AND DISPOSAL 18 2.7 SECURITY IN SDLC 19 3. ASSET AND THREAT TAXONOMY 20 3.1 ASSET TAXONOMY 20 3.2 THREAT TAXONOMY 26 3.3 EXAMPLES OF ATTACK SCENARIOS 43 3.3.1 Insecure Credentials in Embedded Devices 43 3.3.2 Lack of Flexibility to Secure Communications 45 3.3.3 Insecure Software Dependencies in Cloud Services 47 4. GOOD PRACTICES FOR SECURE IOT SDLC 49 4.1 SECURITY CONSIDERATIONS 49 4.2 GOOD PRACTICES 50 4.2.1 People 51 3 GOOD PRACTICES FOR SECURITY OF IOT NOVEMBER 2019 4.2.2 Processes 52 4.2.3 Technologies 54 A ANNEX: MAPPING OF SECURITY MEASURES 57 B ANNEX: SDLC STANDARDS AND BEST PRACTICES 119 C ANNEX: SECURITY IN SDLC MODELS 126 D ANNEX: IOT SDLC TESTING 129 4 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

EXECUTIVE SUMMARY

This ENISA study introduces good practices for IoT security, with a particular focus on software development guidelines for secure IoT products and services throughout their lifetime. Establishing secure development guidelines across the IoT ecosystem, is a fundamental building block for IoT security. By providing good practices on how to secure the IoT software development process, this study tackles one aspect for achieving security by design, a key recommendation that was highlighted in the ENISA Baseline Security Recommendations study which focused on the security of the IoT ecosystem from a horizontal point of view. Software lies at the core of every IoT system and service, enabling their functionality and providing value added features. The firmware of IoT devices, implementations of IoT communication protocols and stacks, Operating Systems (OSs) for IoT products, Application Programming Interfaces (APIs) supporting interoperability and connectivity of different IoT services, IoT device drivers, backend IoT cloud and virtualization software, as well as software implementing different IoT service functionalities, are some examples of how software provides essence to IoT. Due consideration to supply chain issues, including integration of software and hardware, is given. Making use of secure Software Development Life Cycle (SDLC) principles is an effective and proactive means to avoid vulnerabilities in IoT and thus assist in developing software applications and services in a secure manner. Several security challenges of the IoT can be addressed by establishing a baseline of secure development guidelines, such as checking for security vulnerabilities, secure deployment, ensuring continuity of secure development in cases of integrators, continuous delivery etc. It is therefore important to analyze the relevant IoT cybersecurity threats and accordingly to set forward security measures and specific secure development guidelines to avoid common software vulnerabilities deriving from insecure practices that might be followed throughout the SDLC (requirements analysis, software design, software development, implementation, deployment, integration, maintenance and disposal). The main contributions of the study include:  Analysis of security concerns in all phases of IoT SDLC and key points to consider.  Detailed asset and threat taxonomies concerning the IoT secure SDLC.  Concrete and actionable good practices to enhance the cybersecurity of the IoT SDLC.  Mapping of ENISA good practices to related existing standards, guidelines and schemes. The study is mainly targeted at IoT software developers, integrators and platform and system engineers and aims to serve as a point of reference for secure IoT development. Security considerations and guidelines for all phases of software development are provided, starting from requirements, software design and development/implementation, all the way to testing and acceptance, integration and deployment, as well as maintenance and disposal. 5 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

The study underlines the need to consider end-to-end IoT security, not only focusing on smart devices, network protocols and communications, but also taking a step back and methodically integrating cybersecurity by design principles throughout the software development lifecycle. 6 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

1. INTRODUCTION

IoT is at the core of operations for many Operators of Essential Services (OES), as defined in the NIS Directive, especially considering recent initiatives towards Smart Infrastructures, Industry 4.0, 5G, Smart Grids, etc. With a great impact on citizens’ safety, security and privacy, the IoT threat landscape is extremely complex. Therefore, it is important to understand what exactly needs to be secured and to implement specific security measures to protect the IoT from cyber threats. ENISA has published studies on both baseline IoT security recommendations, as well as sectorial IoT security good practices (e.g. smart manufacturing, smart cars, smart hospitals, etc). While the horizontal and vertical IoT security measures greatly assist in reducing relevant risks, the design, development, deployment and configuration of secure IoT solutions should not be neglected. ENISA strongly recommends security and privacy by design and by default. Accordingly, an effective and proactive means to reduce the number and severity of vulnerabilities in IoT is to develop applications in a secure manner, making use of secure Software Development Life Cycle (sSDLC) principles and developers trained in secure coding. Several security challenges of the IoT can be addressed by establishing a set of secure development guidelines, such as checking for security vulnerabilities, secure deployment, ensuring continuity of secure development in cases of integrators, continuous delivery etc. In this regard, the aim of this study is to define a set of good practices and guidelines to be applied in the different phases of the secure SDLC of IoT solutions. During this study, experts were asked what the main phases of the SDLC were. The vast majority of them considered that the SDLC comprises up to six phases, as shown in Figure 1. Figure 1: SDLC phases 7 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

1.1 OBJECTIVES This ENISA study aims to address the cybersecurity challenges related to the SDLC of IoT systems and services. The main objectives were to collect good practices, to foster cybersecurity across the different phases of the IoT SDLC, while also mapping the relevant assets, threats, risks and attack scenarios. To this end, the following objectives have been set:  Analyse the different IoT SDLC phases and underline key cybersecurity challenges in each one.  Identify IoT SDLC assets to protect.  Identify key cybersecurity threats and attack scenarios targeting the IoT SDLC.  Map identified threats to assets.  Identify security measures and map them to attack scenarios and threats.  Identify SDLC principles for IoT code developers. Accordingly, the study aims to promote collaboration for IoT security in Europe and to increase awareness of threats and risks, with particular focus on the secure SDLC of IoT systems and services. In addition, the study will serve as a reference point for future developments and provide a solid basis for securing IoT software from the requirements analysis to maintenance and disposal. 1.2 SCOPE This ENISA study outlines good practices for IoT security with a particular focus on securing SDLC of IoT systems. This entails defining security measures that apply to the entire IoT ecosystem (devices, communications/networks, cloud, etc.) in order to bolster the security of the development process. During this study, ENISA identified available documentation and standards on IoT security, with a focus on SDLC and its different phases. ENISA also collected inputs from a number of IoT security experts through a questionnaire and a series of interviews. Following a thorough analysis of the identified material and the review of security experts feedbacks, ENISA identified the main IoT assets and threats targeting the SDLC. Based on these threats, a set of security measures and good practices were defined to ensure integration of security across the different phases of the IoT SDLC. 1.3 TARGET AUDIENCE This study defines good practices for security of IoT, focusing on securing the SDLC of IoT systems and services. Given the diverse phases that SDLC entails and the complexity of the IoT ecosystem, the target audience of this study comprises the following profiles:  IoT software developers  IoT platform, Software Development Kit (SDK) and Application Programming Interface (API) developers and consumers  IoT integrators 1.4 METHODOLOGY This ENISA study was carried out using a five-step methodological approach as shown in Figure 2. 1. Scope definition and identification of experts: The first step was to establish the scope of the study and to pinpoint the main topics to be considered. A concurrent activity involved identifying the relevant IoT subject matter experts to contribute. The experts (members of ENISA informal expert groups on IoT and Industry 4.0 security, 8 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

IoTSec and EICS respectively) provided input and expertise in relation to the objectives of this report. 2. Desktop research: Extensive research of relevant efforts to gather as much information as possible on securing the IoT SDLC and secure SDLC in general. The identified documents included existing good practices, publications, standards and other initiatives on the topics related to the objectives of the report. This served as support for the analysis of the threats and for the development of the security measures. 3. Questionnaire and interviews with identified experts: ENISA reached out to the identified experts in order to collect information and get their point of view. To this end, an online questionnaire covering various security aspects, such as critical assets, key threats targeting IoT SDLC and awareness with respect to IoT SDLC standards and guidelines, was developed. The questionnaire was completed by the identified experts, and interviews were conducted with experts to collect additional valuable inputs to prepare the report. 4. Analysis and development: The results from the desktop research, online questionnaire and the interviews were analysed to align them with the objectives of the report, developing the asset and threat taxonomies. This helped to identify the attack scenarios, as well as the IoT SDLC security measures. This led to the development of the first draft of this report. 5. Report write-up and validation: ENISA shared the draft of the report with its relevant stakeholder communities and reference groups for review. Taking into account the stakeholders feedbacks, the final version of the report was issued and a validation th face-to-face workshop was organized (on the 8 of October 2019 in Brussels, Belgium) to present the study results and discuss relevant cybersecurity recommendations. Figure 2: Methodology followed in the study 9 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

1.5 STRUCTURE OF THE DOCUMENT The report is structured as follows:  Chapter 1 - Introduction: provides introductory information to the report and introduces the scope, objectives, and the methodology followed.  Chapter 2 – Secure IoT SDLC: discusses cybersecurity considerations in the different phases of IoT SDLC. An asset taxonomy is also presented in accordance with their perceived criticality.  Chapter 3 – Asset and Threat taxonomy: identifies the security threats affecting IoT SDLC and details some examples of potential attack scenarios. Detailed description of threats and mapping to the corresponding assets that they might impact.  Chapter 4 – Good practices for security of IoT SDLC: lists and describes good practices and security measures to secure the IoT SDLC. Further details are provided in the appendix:  Annex A: Comprehensive description of security measures discussed in Chapter 4 and mapping of the security measures to previous work carried out in the field and to the corresponding threats that they are intended to mitigate.  Annex B: List of standards, good practices, security initiatives and other works that have been used in the mapping of Annex B.  Annex C: Introduction of the notion of security across different IoT SDLC models.  Annex D: List of IoT SDLC testing solutions and methodologies. 10 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

2. IOT SECURE SDLC

Software lies at the core of every IoT system and service, enabling their functionality and providing value added features. The firmware of IoT devices, implementations of IoT communication protocols and stacks, Operating Systems (OSs) for IoT products, Application Programming Interfaces (APIs) supporting interoperability and connectivity of different IoT services, architectures that enhance the IoT interoperability, such as Manufacturers Usage Description (MUD) , IoT device drivers, backend IoT cloud and virtualization software, as well as software implementing different IoT service functionalities, are some examples of how software provides essence to IoT. However, the pervasive nature of software across the IoT ecosystem and its role as a central cog in the entire IoT supply chain , bring security risks. Adversaries may exploit software vulnerabilities to compromise the security of IoT systems and services and impact the proper operation of such systems and services. The entire IoT ecosystem, taking into consideration also the Internet and the external physical systems that make use of IoT need to be taken into consideration when calculating risk. It is therefore evident that systematically securing IoT software is essential throughout the lifetime of IoT systems and services in order to deliver resilient, reliable and failsafe solutions. In this respect, the IoT Software Development Life Cycle (SDLC) as a whole needs to be secured and proper considerations to be taken into account by all involved stakeholders from the beginning of the software development process up to maintenance and disposal. However, securing IoT, and especially IoT edge-devices, can prove a difficult task for software developers if hardware comes without basic security capabilities. For example, when implementing a strong cryptographic algorithm in the software stack, it is the use of a Trusted Platform Module (TPM) in the hardware that will ensure the private key cannot be exposed. Therefore, software development for IoT cannot neglect the underlying hardware, which in turn entails that the security approach has to conceive it as a set where the design of hardware influences the design of software. Elements such as the Root of Trust or Chain of Trust are good examples of how software and hardware are related and interconnected and result in joint security considerations to confront current IoT vulnerabilities such as vulnerabilities in communication stack derived from hardware implementation (e.g. which could be faced implementing a hardware isolation and secure boot). SDLC is a process consisting of different phases that aims at delivering effective and efficient systems as per their design and functional requirements. There are many ways to achieve this goal, which are represented by various SDLC models as described in the following. Accordingly, incorporating security considerations takes place in a different manner based on the adopted SDLC model. By methodically considering security across all phases of IoT SDLC and applying appropriate security measures on the corresponding assets that may be affected, the overall security of the IoT ecosystem is improved. 11 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

Securing the IoT SDLC process involves securing the SDLC process across all elements of the IoT ecosystem, namely IoT end devices, communications, cloud backend and applications for mobile devices for controlling devices . Moreover, all types of software running on the aforementioned elements should be considered, including but not limited to end device firmware, IoT services/software implementations, network protocol implementations, API source code, IoT gateways source code, software running on backend cloud servers, etc. It becomes clear that the complexity and heterogeneity of the different IoT elements and types of IoT software both exacerbate cybersecurity issues and therefore there is a growing need to come up with homogeneous, good practices for securing the SDLC. Security considerations of the different IoT SDLC phases are discussed in what follows. 2.1 REQUIREMENTS Requirements are the foundation for all that is to follow in the IoT development cycle. During this phase user, business and functional requirements of the software are being defined. These requirements reflect the intended use of the software and will be translated to specifications that will guide design, development and maintenance/deployment decisions at a later stage. Accordingly, it is essential to consider security from this first phase of software development, in order to ensure as much as possible that security by design principles are taken on board and that security does not come as an afterthought. In this respect, during the requirements phase it is essential to conduct a preliminary identification of software security aspects taking into account the aforementioned (user, business, legal, regulatory and functional) requirements . Indicative security requirements include user password change policies, the need to implement a business recovery plan, the ability to stay up to date, etc.), cost – benefit and risk analysis results, as well as ones that refer to the external environment. The latter include for example third-party dependencies, security standards and/or certification objectives, potential IoT threats, possible IoT attack vectors, etc. For the sake of quality assurance, it is considered a good practice to monitor and review the requirements periodically throughout the SDLC. The former will ensure that security is in line with the general requirements of the software and ensure consistency in development. Security engineers will need to work with software engineers and business analysts in order to guarantee the optimal convergence of the two fields. The latter are externalities to the software itself and usually outside the realm of control of the software engineers. However, they are used to define security assumptions about the software under development. For example, likelihood of critical threats, levels of trust to be placed on user accounts, likelihood of attack vector realization, etc. should be considered. Therefore, the requirements phase in the context of security yields two outputs: a set of security requirements that depends on the context (connectivity type, target environment specifics, etc.), as well as a set of security requirements that depends on the functionalities offered by the solution (business or use cases) . Additionally, another important aspect to consider during the identification of requirements is the physical or hardware requirements needed for development (functional requirements), since software and hardware are closely related. As part of the system, the security requirements of software may have certain implications when selecting the physical media (hardware), which have to be addressed during the SDLC process. Specifically, the security requirements in the Requirements phase will entail considerations for the selection of hardware in the definition of the architecture during the Design phase. For instance, if the implementation of a secure boot 12 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

mechanism is selected as a requirement, it will be necessary for hardware to support this type of Root-of-Trust (RoT) mechanism, potentially requiring the inclusion of physical hardware security modules (HSM) to manage cryptographic keys. Thus, physical requirements become as much an aspect for consideration as requirements for communications, processing capacity required, hard disk space, etc. To ensure consistency of all above types of requirements, one commonly used technique is that of quality gateways . These gateways receive requirements as input and they check them for completeness, relevance, testability, coherency, traceability and several other qualities. In the context of security, other interesting techniques include bug bars . A bug bar is an example of quality gates, which is used to define the severity thresholds of security vulnerabilities (E.g. no known vulnerabilities in the application with a “critical” or “important” rating at time of release). Risk analysis, as well as making use of best practices documents (e.g. OWASP IoT Top10 ) and guidelines also help to secure software development by means of predefined checklists of most common security risks and pitfalls. Risk analysis also involves identification of the assets that will comprise the software system or service, as well as their interactions and external dependencies. This may be used to pinpoint asset criticality, data flows and allowed operations on data, thus yielding significant input to improve software security. While drawing up requirements, the concept of threat modelling should be borne in mind. It assumes that potential threats, such as structural vulnerabilities, can be identified, enumerated, and prioritised. Most commonly, the STRIDE (Spoofing, Tampering, Information Disclosure, Repudiation, Denial of Service and Elevation of Privilege) methodology is used to identify and classify threats. Threat modelling starts in the requirements phase with the identification of critical assets and is completed in the software design phase, when the risks have been evaluated and ranked, and their mitigation has been planned . With IoT, the digital and physical worlds are no longer kept apart from one another. The cyber physical nature as well as the diverse components and application domains of IoT introduce additional parameters in the threat modelling equation. These include the consideration of industry-specific threats that may apply, such as interoperability with legacy-coded and outdated devices. Given the dynamic evolution of IoT ecosystems and their inherent adaptation to changing context, it is evident that requirements identification should cater for flexibility throughout the lifetime of IoT products and services. In terms of securing the IoT SDLC, this translates to iterative rounds of security requirements identification and the need to consider all possible use case scenarios of the IoT system or service. 2.2 SOFTWARE DESIGN During the software design phase the on device architecture and the design of the IoT solution are created. This phase involves the creation of a set of documents that describe how the user/business and functional requirements will be translated to system specifications and essentially how the IoT solution will work. Therefore, it is important to make sure that 13 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

specifications meet all the requirements defined in the previous phase. For instance, in IoT devices the specifications for user passwords should be included as requirement. In turn, during the design phase, this would entail implementing functions to manage user passwords as required (change cycles, minimum password length, special symbols, etc.). From a security standpoint, a risk-based approach that identifies pertinent threats is followed to incorporate security in the software design. The security requirements established in the previous phase are being reviewed using threat modelling and attack surface analysis techniques. Threat modelling is the backbone of the security activities carried out during the definition of security requirements, but can also be further refined during software design. Additionally, attack surface analysis should consider the attacker’s potential motivations, intentions and capabilities, as well as the attack avenues of the system, the impact and the probability. As stated in requirements section, risks can also be entailed by business features. For this reason, it is necessary to design specific security controls to prevent such potential issues. Effective identification and mitigation of security threats in early design phase needs to be prioritized as it can be very hard to mitigate them in later phases of the development lifecycle. Moreover, other provisions in the software design, such as the chain of trust and recovery plan of the solution and the integration of security mechanisms (FOTA, remote credential management, etc.) in this phase safeguards the operation of IoT systems and prevents costly security implementations into IoT solutions after they have been developed or during the remote sustain/maintenance . Architectures primarily focus on overarching, cross-cutting concerns for the IoT system that pursue mainly high scalability and integration of diverse technologies and systems. A security architecture for IoT relies mainly on the CIA triad (Confidentiality, Integrity, and Availability). In addition, other relevant aspects like access control, policy configuration, or security lifecycle should be considered. Guidelines, secure design patterns and principles aid in this mission. These principles apply to the design of any IoT solution, although there may be variations depending on the specific functionalities or limitations of the component being designed or the context in which is going to operate. For instance, cloud platforms require privilege-based administration roles, and, depending on the use case, IoT devices may require updates and measures that reassure minimum disruption . However, IoT is highly related to the cyber-physical world and, in this respect, in addition to the CIA triad, safety implications are pertinent and particularly relevant when designing an IoT solution. Due to the use of sensors and actuators that act as frontiers between the logical and physical worlds, safety aspects and considerations should also be considered during the design phase. For instance, if the design principles are not used, a software solution could be built without taking into account the “least privilege principle”, so an attacker could leverage this vulnerability to take control of an automated process and cause a process malfunction, which in turn could have a significant impact on human safety. 14 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

2.3 DEVELOPMENT/IMPLEMENTATION In the Development/Implementation phase, specifications and software design diagrams written in an appropriate notation are transposed into code. Therefore, what is defined in the two previous phases plays a crucial role in the successful execution of the development process. The foundation of IoT secure software development relies on secure code. Code should be built, tested, integrated, maintained, and updated with security aspects in mind. Risk mitigation as evaluated by means of the threat model carried out in the Design phase is implemented in the code. Given the hardware and software constraints of IoT devices, integrating security in the code of this ecosystem poses challenges to developers as they can't build a code base with fullfledged security as in traditional IT systems. Code must be optimised to ensure that every instruction counts but, at the same time, secure development practices (e.g., SANS Top 25 Software Errors ) and appropriate security solutions for all different elements, such as access interface, applications, data and device layers, need to be leveraged. For example, in IoT communications, the use of lightweight authentication and encryption have proved to be good security techniques that fit to the specific purpose. In the IoT space, product releases may vary in frequency. Coding needs to keep the pace and 20 21 to that end, the use of secure code guidelines and coding standards can prove extremely helpful to the developers to identify known vulnerabilities, avoid insecure coding practices and use the built-in security specific features that certain programming languages may offer. Additionally, there are tools and methods to verify the quality of security for software development languages. Secure IoT frameworks offer to developers a rapid and effective manner to integrate security components, prevent security weaknesses and provide security by design from the beginning of the development. To ensure continuous secure software coding operations, software development should be accompanied by continuous integration of security best practices and assessments. Fundamental testing activities should be consistently addressed in this phase. This way, only a signed-off build is propagated to the next phase. A realistic way of maintaining security in an environment that grows so rapidly and changes so quickly is to automate it. Automated tools such as Static Code Analysis tools are a useful complement to manual inspection of code to help detect security issues during the software development phase. Static Application Security Testing (SAST) methodology allows the automation of the security process and enables early elimination of application-layer vulnerabilities. Although SAST takes place in the case of continuous integration (Agile / DevOps / DevSecOps) it can be carried out manually in other software methodologies. Conversely, other less automated activities- like code review, 24 25 build environment, anti-tampering techniques, and configuration management , -complement the testing and verification process determined to improve resilience. Especially for IoT, it is a common practice for developers to consume third-party APIs, frameworks, libraries and tools (either commercial off-the-shelf-components (COTS) or open source software (OSS)) for the compilation and the build process. In a world where there is no need to reinvent the wheel, this approach brings numerous benefits as it allows developers to focus on product-specific features and reduce time to market and development costs. However, 15 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

these third-party components are often treated as black boxes and are less scrutinized than internally developed components; hence they come with risk. It is essential to be aware of the vulnerabilities that derive from these components and they should be considered and evaluated before integrating them into the IoT system. For example, specific parameters should be checked before using these external components, such as active community support for OSS components, current market use of these components, integration-ready state, latest version available, supporting documentation, frequency and number of reported CVEs, etc. It is also a good practice to use well-established and secure libraries and frameworks, so that the final outcome is less prone to inherit security vulnerabilities of the components that it integrates. 26,27,28,29 IoT development requires a standard approach to developing secure products. When developing software, it is important to organise the process so that developers can work on new versions that are less vulnerable or provide better services. Configuration management integrates processes, policies and tools to make software systems more secure and flexible. In this regard, Version Control Systems (VCS), secure bootstrap capability and other equivalent methods become noteworthy means to achieve these goals. 2.4 TESTING AND ACCEPTANCE The testing and acceptance phase involves all necessary steps to verify that the developed software actually meets the identified requirements and design principles of the previous phases. For this reason, a variety of tests (each serving a different purpose) are performed on the software. These tests may be automated or manual, and both the source code (static analysis) and the running software (dynamic analysis) need to be checked. Automated tests may significantly reduce the required time to conduct them compared to manual tests and they can also increase consistency and efficiency by being highly scalable. Conversely, they introduce an additional degree of uncertainty in the testing phase and need to be redesigned to be more effective. This uncertainty results from the size of the code base to which the tests are applied and from the poor design for a larger scale of applications, since they can produce varying numbers of false positives/negatives compared to manual testing . During the testing phase, it is therefore important to assess the particular needs of the software product and establish the most suitable and efficient testing strategy and build the appropriate testing environment (e.g. simulated or emulated environment, digital twin, test datasets, capturing of outputs for post-processing, fuzzing, pentesting, sandboxing, etc.). In terms of security, testing during this phase (e.g. fuzzing testing,- see Annex D) helps to verify the proper and effective use of identified security measures and controls, as well as to identify and highlight potential vulnerabilities and weaknesses already present in the developed software prior to integration and deployment. In particular for the IoT SDLC testing phase, it is important to consider all elements of the IoT ecosystem as previously described, i.e. IoT end 32,33 devices, firmware and communications . There is an added level of complexity in designing and building an appropriate testing strategy and a testing environment for IoT systems and services, given the many interdependencies of the numerous fundamental elements of IoT. It is 16 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

thus important to carefully plan and ensure that all interfaces, data flows and externalities are fully and correctly assessed during testing and acceptance. An important aspect of testing and acceptance is that of code review. While this may be considered an advanced and time-consuming solution (especially considering the large variety of many IoT systems and services and the frequent use of third-party libraries), this type of test may expose underlying software vulnerabilities and weaknesses that are undetectable by other techniques (e.g. logic bombs). For a comprehensive listing of SDLC tests, the reader may refer to Annex D. Based on risk and threat assessment and taking into account security requirements and software specifics, the selection of the most suitable testing suite should be performed. 2.5 DEPLOYMENT AND INTEGRATION The deployment and integration phase follows the acceptance of the software subject to successful testing in the previous phase, i.e. after it has been approved for release. It involves integrating all necessary elements of the software in the production environment and its deployment. Deployment should be carefully planned, executed and communicated to all actors involved (e.g. end users, production teams, development teams, integrators, etc.), in order to ensure a smooth deployment in the target environment. This is particularly challenging in the IoT realm, given the many interdependencies involved and the fact that IoT solutions are usually deployed in widely open environments, where administrators and the support team might not have full control. Another particularity of IoT deployment involves the heterogeneity of deployment environments, e.g. IoT devices for firmware solutions, cloud-servers for back-end IoT services, gateways and network components in the case of IoT communication protocols implementations, etc. It may also be the case that an IoT software project could require aspects of all these possible deployment environments or target environments (e.g. whether an IoT device meets the requirements, or if the security configuration of an IoT device needs to be adapted to the target environment). Therefore, choosing the right deployment strategy (e.g. Canary, A/B testing, Blue/Green, etc. ) is of paramount importance and requires to weight options like the impact of change on the system and/or on the end-users, rollout/rollback timings, downtime requirements, etc. An important step in secure IoT deployment is that of asset and user authorization. To this end, adaptive user-rights administration interfaces, device authentication and user authentication mechanisms are beneficial. Additionally, IoT systems allowing self-enrolment should provide a means for an administrator to check and accept or reject the enrolment request. Furthermore, security risks involved with deployment should be given proper emphasis in the deployment and integration phase. The aim is to be able to maintain secure, stable and failsafe operation of the software during deployment and for this reason appropriate metrics are monitored to ensure the “health” of the running, “live” software. Such metrics might include number of bugs reported, number of identified vulnerabilities and weaknesses, number of exploit attempts, etc. An essential part of deployment involves change management and in the case of IoT SDLC this mainly refers to software updates. The latter mainly support configuration and vulnerability management, but may also be needed for other reasons. All patches should follow a structured change management approach and, in the case of security, should ensure that any updates to the system retain at least the same level of security that was provided by the previous solution. In terms of deployment for IoT systems and services and software updates, an added level of 17 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

complexity derives from the fact that these mostly take place over the air, via wireless channels and making use of backend servers for the propagation of patches. It is evident that all these elements increase the potential attack surface and therefore should be mitigated by appropriate security controls. Software updates and patch management are also among the tasks of the forthcoming phase, namely maintenance and disposal. 2.6 MAINTENANCE AND DISPOSAL The last phase of IoT SDLC involves maintenance and disposal. It is important to not disregard activities and tasks that fall under this phase. This is because software deployed in production needs to be constantly maintained to ensure availability and integrity of the provided functionality. The pervasive and adaptive nature of IoT solutions and the fact that devices may be appropriated by users, further strengthens the need for maintenance operations. In addition, given the fact that IoT end devices are many times located in uncontrolled or mission-critical environments and even in outdoor settings, maintenance planning should integrate relevant features (e.g. consistent remote secure (over-the-air) update procedures, updates assuming no physical access/no user-interaction, intuitive update timings with minimum disruption, etc.). Moreover, in terms of security, incident management is an ongoing activity during maintenance. All elements of the software, as well as all other integral parts of an IoT solution need to be continuously monitored to ensure threat detection and response. It is thus a good practice to perform frequent vulnerability assessments, penetration tests, security maintenance and threat intelligence tasks to prevent attacks and threats to the cloud, the network and IoT end devices, 35 36 as well as the applications developed for such devices. Constrained and low-powered IoT devices may not able to create or store log files, so preparing for accountability is very important. In addition, service continuity planning by means of automatic backups or redundancy helps to prepare for malfunctioning or service disruptions caused by security incidents. Other maintenance and disposal tasks include management of software updates, regulatory compliance (by monitoring the corresponding legal and regulatory framework) and secure software and device disposal. Similarly to the previous phase, management of software updates needs to cope with the particularities of the IoT ecosystem. One additional element to consider is the lifetime of IoT devices, which in some cases might be long (e.g. smart car). Combined with vulnerability management, security patches and updates should be issued in a timely and reliable manner. Recent interesting related work includes IETF SUIT (Software Updates for Internet of Things) . Additionally, it is important to ensure that when IoT maintenance functions are delegated to third parties (contractors), this takes place in well-looked-after security conditions, i.e. access control, permission handling, audit and accountability. Lastly, when IoT software becomes obsolete (for example, when a product series of IoT end devices is decommissioned), it is important to ensure a secure disposal to preserve privacy management, providing data erasure mechanisms. The main risk involved is the abuse of the various types of data that the IoT software makes use of and has probably cached for processing. Such sensitive data types could include patient health records, Wi-Fi credentials to access the organisation/enterprise network, or operational knowledge used to gain a competitive advantage. 18 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

2.7 SECURITY IN SDLC An important aspect that is commonly overlooked when integrating security in a process (such as in the SDLC) is that of assessment and evaluation. Understanding the current cybersecurity posture is the first step towards establishing a plan to maintain this posture and improve it. In this respect, Security Maturity Models (SMM) are a very useful tool since they guide organisations to define their level of security in accordance with the requirements they wish to fulfil . The maturity of security assesses the understanding of the current level of security, its needs, benefits, and the cost of its support. This assessment takes into account specific threats to the regulatory and compliance requirements of an organisation's industry, the unique risks present in an environment, and the organisation's threat profile. There are numerous standards that serve as tools to evaluate the security of a software project. Some of the most widely recognised industry standards are: Common Criteria (CC) , Capability Maturity Model 40 41 Integration (CMMI) , Building Security in Maturity Model (BSIMM) , Security for industrial automation and control systems Part 4-1 - Secure product development lifecycle requirements (IEC 62443-4-1), or Open Software Assurance Maturity Model (OpenSAMM) , among others. Throughout the document, security will be addressed from the need to define a procedure to carry out a secure software development process and its management (governance), as well as from the implementation and execution of the necessary measures to that security be embedded during the different phases of the SDLC. Along these lines, security should be a fundamental principle across all six phases of the IoT SDLC. Relevant and applicable controls need to be carried out in each phase to evaluate the state of security (e.g. establishing security gates and metrics). In order to ensure that software meets all required security conditions before proceeding to following phases, it is necessary to implement security gates. The severity thresholds that indicate the completion of each phase are defined by means of metrics. These metrics are used to analyse, detect and correct vulnerabilities throughout the development process. Complementary to security, a cross-cutting activity during the SDLC process that is often not considered as essential is the documentation process. This is due to the complexity of the IoT solutions, the number of resources involved in a development process, the IoT interconnectivity, the number of external and internal components, the module integrations, configurations, designs, requirements, etc. It is crucial to have a good documentation and a documentation management system that supports the SDLC process to make it understandable, traceable, and subject to monitoring and auditing. 19 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

3. ASSET AND THREAT TAXONOMY

3.1 ASSET TAXONOMY To focus on the details of IoT security in the SDLC it is essential to start from identification and decomposition of assets of such vast and complex environments focusing on software development. Here we provide an overview of the key asset groups and assets that need to be protected. IoT SDLC assets are classified into key groups depicted in Figure 3 and described in Table 1. It should be noted that the lowest level of the taxonomy is indicative and not exhaustive. For instance, not all types of data are listed, just some representative ones. 20 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019 Figure 3: Asset taxonomy

21 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

Table 1: Asset taxonomy

Asset group Subgroup Indicative assets Description

Individual or team responsible for analysing data that are

Business owners /

used by a business or organisation or a specific business

BI analysts

function.

People in charge of the quality of the software (QA staff),

Testers Q/A

by means of checking it.

Specialist people in putting different IT components

Integrators

together, working as a whole system

Software Developers People that develop software applications

Software Team

Expert who makes high-level design choices and dictates Software Architects technical standards, including software coding standards, tools, and platforms.

Designers responsible for the user interface of an IoT

UI/UIX Designers

application that need to work closely together.

Software designers that use principles of science and

Software Designers

mathematics to develop IoT applications.

(Chief) Information International Standards and Best Practices applicable in Security Officer the work process management

Human factor

Security engineers are responsible for the security aspects in the design of systems that need to be able to

Security engineers

deal robustly with possible sources of disruption, ranging from natural disasters to malicious acts.

Security Team

Professional specialized in security that attempt to crack

Penetration Testers

into a system for the purposes of security testing.

Group of people who prepare for and respond to any Incident Response Team emergency incident, such as a natural disaster or an interruption of business operations.

Operators/Administ

People with this role undertake ongoing activities that are

rators/DevOps/SRE

required for the provision of IoT software or services.

(Operations Team)

End Users People that use the software applications

Contractors/Sub- Entities or companies that provide services or products contractors relevant to the processes of IoT software development.

Project managers are accountable for the success of a Decision makers / project and their responsibilities include the planning and Project Managers the execution of a project, building its comprehensive work plan, and managing the budget.

High-level description of what the intended product or Business requirements services should do based on the business and/or stakeholders needs

Software design Requirements Quantifiable measures that are used to track and assess

Metrics

Security the status of a specific business process.

assessment

s Quality Methodology for the quality assurance of an SDLC gateways process.

22 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

Methodology used to identify and analyse the behaviour

Use cases

of a system when responding to an event.

Detailed and technical documents that describe the

Specifications

technical functionalities of the end product or service.

Tools to aid in the design software or systems, also Design Tools known as CASE tools: Computer Aided Software Engineering.

Hardware components

Firmware

Underlying Operating Systems Components on which the intended software relies or is components (ROS) built on.

Compilers

Simulation environments

Software security checklist

A set routines or practices that streamline a particular

Guidelines

processes.

Manuals

Software A multi-layer technology that enables management tasks

IoT platforms

development and data visualisation.

Software development kits: a set of functionalities and SDKs tools to allow developing software in a programming language.

A set of functionalities and libraries to ease and speed up Frameworks the software development, being the foundation of software applications.

Development tools

Integrated development environment: software IDEs application that provides a set of tools to aid in software development.

Algorithms to perform a task without instructions, resorting to patterns and inference. A subset of artificial intelligence, the algorithms that make a mathematical Algorithm Training tools model from "training data" depend on the kind of problem, the computing resources available, and the nature of the data (supervised, unsupervised, classification, regression, etc.).

Integration

A set of guidelines for creating and designing test cases.

Automation testing

It is a conceptual part of automated testing that helps

frameworks

testers to use resources more efficiently.

Security

Software Deployment strategies provide a way to change or

Deployment

deployment upgrade an application without downtime in a way that

strategies

the user barely notices the improvements.

A solution that uses different protocols and standards Web-services with the objective of exchanging data between applications.

23 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

System designed to perform some dedicated functions, typically with low resources, and sometimes located remotely. Embedded Systems with updatable software or

Embedded systems

firmware include a bootloader which is responsible for verifying the integrity of the software or firmware image on the device before loading it.

Software package that contains everything the software Containers / VMs needs to run. This includes the executable program as well as system tools, libraries, and settings.

Continuous Integration and Delivery: Continuous Integration is the engineering practice of frequently

Orchestration and

committing code in a shared repository. Continuous

CI/CD playbooks

Delivery is the practice to build the software in a way that is always ready to run in their target environment

Applications where the management and allocation of Serverless servers and resources are completely managed by the cloud provider

Cloud computing: the on-demand availability of computer

Cloud services (e.g.

system resources, especially data storage and

device

computing power, without direct active management by

provisioning)

the user.

Integrity Software that protects against unexpected or verification unauthorised changes in data once it was created by an software authorised source.

Reporting data/ Big These data inform of critical elements concerning an data analytics organisation's performance to improve different aspects.

Without these data it would not be possible to complete

Production Data

daily business tasks and processes.

Security copy of data files and folders to enable recovery

Backup Data

in the event of data loss.

Configuration Data Data needed to set up the system correctly

Operation Data Real data with which the software works

Data

Platform that stores and centralizes all the developed Code repository source code. Allows the development team to keep track of versions.

Data used to perform the different tests concerning

Test Data

software, e.g. penetration testing, black box testing, etc.

This repository provides a single, centralised database to

Asset repository

store and track organisational assets.

Data used to train Artificial Intelligence/Machine Learning algorithms. Training involves the learning phase where

Training data

algorithms can make predictions based on the training data that been fed to them.

Over-the-Air (OTA) Mechanism to update hardware remotely with new update mechanism settings, software or firmware.

Maintenance Updates

Software that sets the lowest-level logic to control a

Firmware

device‘s electronic circuits.

24 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

Minor software modifications deployed that provide

Software

security or functionality error fix.

Software component that provide functionality for other

Back-end servers

programs such as sharing data or resources

Support/ Ticketing Software designed to organise and distribute incoming system customer service requests.

Monitoring tools used to continuously keep track of the status of the system in use, in order to ensure the earliest Monitoring tools / warning of failures, defects or problems, and to improve SIEM them. Monitoring tools span from servers, networks, and databases, to security, performance, end-devices and applications.

Threat Intelligence Services generate, aggregate and

Threat Intelligence

distribute real-time feeds of intelligence data generated

services

and derived from the use of IoT.

Source Code

Change management Written text or illustration that accompanies Software and explain how operates or how to use it. Different types of

Documentation

documentation exist such as that for source code,

Disaster recovery

change management, etc.

Third-party documentation

The practice used by organisations to detect and prevent breaches, leakages, or the undesired destruction of Data loss sensitive data. Also used for regulatory compliance. An prevention example would a ransomware attack. DLP focuses on preventing illicit transfers of data outside of the organisation.

Management of the different changes made to the

elements of a product or its configuration.

Software readily available for users to build and distribute

Open-source code

new solutions.

Commercial-off-the-shelf: software and services are built and delivered usually from a third party vendor. COTS

COTS

can be purchased, leased or even licensed to the general public.

Code

Software developed and maintained by the own

Own software

company.

Software not developed or maintained by the company, Software Third-party libraries but they are part of an application or system of the components company

Own

Application Programing Interface: a set of subroutine APIs definitions, communication protocols, and tools offered for one library to be used by other software

Third-party

Technology that is used for authenticating users and

PKI

devices in the IoT ecosystem.

Formal descriptions of digital message formats and rules

Communication

that allow two or more entities of a communications

protocols

system to transmit information.

25 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

Identity and Access A framework of business processes, policies and Management technologies that facilitates management access control.

A set of unambiguous specifications for performing Algorithms/Logic calculation, data processing, automated reasoning, and other tasks.

Relational (SQL) Database

Software packages designed to define, manipulate,

management

retrieve and manage data in a database

systems Non-relational (NoSQL)

Any type of tangible asset that is used to support the

Physical assets

SDLC process (e.g. computers, wires, etc).

Network

Utilities

Intangible assets in the form of internal or external Support servicers services that support the operation of the SDLC infrastructure.

Cloud

SDLC Third-party services infrastructure

Development

Environment and networks used for the development of

environment and

the IoT applications.

networks

Testing

Environment and networks used for testing purposes of

environment and

the IoT applications.

networks

Integration

Environment and networks used for the integration of the

environment and

IoT applications.

networks

3.2 THREAT TAXONOMY The complexity and large scale of the IoT SDLC process combined with the inherent particularities and challenges of IoT systems and services exacerbate relevant cybersecurity challenges. There exist a series of threats that might affect the IoT SDLC, while it should also be noted that these threats come with a varying level of potential impact if they materialize. In accordance with the ENISA Threat Taxonomy , Figure 4 depicts the main threats related to the IoT SDLC. Further details are provided in Table 2, where a detailed description of all threats is listed, alongside the list of assets (as per the asset taxonomy) that each threat may affect. 26 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019 Figure 4: Threat taxonomy

27 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

28 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

29 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

Table 2: Threat taxonomy and mapping to assets

Category Sub-Category Threat Description Assets Affected

Software Component Theft of data to gather critical and valuable Data information, by an employee or by some other

Corporate

company (competitors), throughout the Human Factor

Espionage

development lifecycle process, affecting the final Software Development product, intellectual property, time to market, etc. SDLC infrastructure

Data

Human factor

Intentional unauthorised actions (non-fulfilment or Software Design defective fulfilment of personal duties) aimed at causing a disruption or damage during the Software Development

Sabotage

software development, to obstruct the process, to SDLC infrastructure affect the integrity of the software or to ultimately compromise the objective of the software. Software components

Software Deployment

Maintenance

Data

Human factor A team member or an attacker may use Software Design confidential information or exploit system vulnerabilities to carry out fraudulent activities Software Development

Insider Threat Fraudulent

(theft of sensitive information, industrial activities SDLC infrastructure espionage, or extortion) that may affect the integrity of the software or cause damages to third Software components parties. Software Deployment

Maintenance

Personnel

A member of the team is under duress from a malicious third party to carry out certain actions that could compromise the security of software in Blackmailed staff Human Factor exchange of not revealing embarrassing, disgraceful or otherwise damaging information about the employee. It is a form of extortion.

A disgruntled employee may deliberately use his or her privileges in order to seek revenge by leaking sensitive information to competitors or Disgruntled staff Human Factor other companies that offer some kind of incentive to the employee to compensate for this dissatisfaction.

A corrupt employee may deliberately seek to exploit his or her privileges in relation to corporate Corrupted staff resources to his or her own benefit, leveraging the Human Factor said resources for personal gain despite not being dissatisfied with the situation at the organisation.

An incompetent/inexperience/demotivated may

Incompetent /

pose a threat to the organisation due to

Inexperienced /

absentmindedness or to a lack of knowledge and Human Factor

Demotivated

awareness of security, resulting in accidental

Staff

risks.

Teamwork Issues

Issues in Lack of a proper communication between project communication/c members, either internals or communications with Human Factor oordination service providers, may lead to errors such as misunderstandings, duplication of tasks,

30 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

undefined scope, lack of systems integration, use of obsolete versions, etc.

A lack or unavailability of necessary personnel (strike, unexpected events, disasters, or staff

Absence of

turnover) may lead to an inability to ensure the

Internal personnel /

level of security required due to the excessive Human Factor

Limitations Limited

workloads burdening other staff members and

resources

preventing them from paying the necessary attention to security throughout the process.

Data

Human factor

A way of activism that uses and/or abuses Software Design technology to spread ideas or to punish The use of illegal organisations or people based on their beliefs. Software Development

Hacktivism

logical tools This threat can be posed either by isolated SDLC infrastructure individuals or by organised professionals taking advantage of an organisation's security flaws. Software components

Software Deployment

Maintenance

Data

Human factor Unavailability of business software required for Business development of the software, failure of business Software Development software software, failure of the support services, or loss of Maintenance the license. SDLC infrastructure

Software components

Unavailability, interruption or failure of online storage on the cloud. Depending on the Software Deployment

Cloud (online

communication, and on the time required to storage) SDLC infrastructure recover, the importance of this threat ranges from high to critical.

Data The failure or malfunction of a service or support Human Factor Third-party that has been assigned to a third party (supplier), Outages services (e.g. thus creating a dependency, can affect the whole SDLC infrastructure

Loss of support

API, product lifecycle, from the development process services Software components Communication (e.g. drawing the project out) to the release of the Brokers, Cloud) product in the market (e.g. unavailability of the Software Deployment service). Maintenance

Data Threat of unavailability documents of private company archives, often a failure of document Human Factor Third party management control affects the specifications of Software Design documentation the software, information leakage / sharing caused by inadequate security measures of the SDLC infrastructure third-party. Maintenance

Data

Software Development Unavailability of the code repositories, due to a

Code

lack support of the repository, failure of the third SDLC infrastructure

repositories

parties, failure of communications, etc. Software components

Maintenance

31 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

Data Software Unavailability of proper software configuration Software Deployment configuration management, unawareness of the correct version management of the code or modification of the code. Software Components

Maintenance

Data

Human Factor Unavailability of subcontracting of development Software Development Subcontracting services required for development process. of development Unavailability of key personnel and their SDLC infrastructure services competences, unavailability of the business Software components development, etc. Software Deployment

Maintenance

Human Factor Interruption or failure in the supply of power Power (Electricity (electricity or gas), either intentional or accidental, Data and Gas) and the time required to recover. The importance SDLC infrastructure of this threat ranges from high to critical. Maintenance

Human Factor Interruption or failure in the UPS, either intentional UPS Data or accidental, and the time required to recover.

Utility outage (uninterruptible

The importance of this threat ranges from high to SDLC infrastructure

power supply)

critical. Maintenance

Human Factor An interruption or failure in the cooling services (air-conditioning in server room), either intentional Data Cooling or accidental, may affect hardware support and prevent access to project information (loss of SDLC infrastructure information, file deletion, etc.) Maintenance

Human Factor A lack of communication links (wireless, mobile, fixed network, internet) prevents information flows Data

Communication

Network outage due to problems with networks blocking file issues SDLC infrastructure updates, repository access, teamwork communications, information exchanges, etc. Maintenance

A member of the team unconsciously makes a Data mistake in any of the tasks, causing an unwanted Source code Software Components modification of source code (and probably damaging it). Maintenance

A member of the team unconsciously makes a Configuration mistake in any of the tasks, causing an unwanted Data data modification of configuration files (and probably Maintenance damaging them).

Unintentional Unintentional Damages

modifications A member of the team unconsciously makes a (Accidental) mistake in any of the tasks, causing an unwanted Data

Test data

modification of test reports (and probably Maintenance damaging them).

The information about how to put the software Data into production, or about how to launch the system (start scripts) is quite sensitive. Errors Software Deployment

Deployment data

concerning these data could leave the software in Software Development a vulnerable state (security measures not activated, etc.) Software components

32 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

A member of the team unconsciously makes a Human Factor mistake in any of the tasks, causing an unwanted Documentation Data modification of project documentation (and probably damaging it). Maintenance

An unexpected modification that affects the Backup Data backups could put at risk the system's operation Data Modification or even bring about a loss of the application in Maintenance case of a system failure.

Data

Software Design

A change of the environmental work conditions Software Development Perturbation of can cause the failure of results in the SDLC SDLC infrastructure environment process (testing results, maintenance and operation environment, etc.) Software components

Software Deployment

Maintenance

Data

Information leakage / sharing / damage or system Software Development Development management misuse that could affect the SDLC infrastructure environment programming process and tools during the development phase. Software Components

Maintenance

Data

Software Design Information leakage / sharing / damage or system Integration management misuse that could affect the process Software Development environment and tools when all software components are put SDLC infrastructure together and tested as a whole. Software components

Erroneous use or

Software Deployment

administration of devices and

Data

systems

Information leakage / sharing / damage or system Software Development management misuse that could affect to the

Testing

validation process and tools (automated checks SDLC infrastructure

environment

or non-automated techniques) causing failed Software components tests, or false test results. Software Deployment

Data

Software Development Information leakage / sharing / damage or system Production management misuse that could modify the current Maintenance environment conditions of the software (such as configuration) SDLC infrastructure during its production phase. Software Components

Software Deployment

Discontinued A failure on the part of a service provider on Software Components third-party which the project depends puts at risk the proper

Damage caused

products operation of the software development process SDLC infrastructure

by a 3rd party

/services for because the corresponding dependency (service Maintenance development or product) will no longer be provided.

A sensitive information exposure occurs when, due to an accidental event, an application or Data

Information Data disclosure

leakage program does not adequately protect information Software Components such as passwords, payment info, or health data. With this information, cybercriminals can make

33 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

fraudulent purchases, access a victim’s personal accounts, or even blackmail someone.

Data

Human factor

Software Design Intentional actions by internal people aimed at Software Development Internal causing a disruption or damage of the physical components or facilities SDLC infrastructure

Software components

Software Deployment

Maintenance

Sabotage

Data

Human factor

Software Design Intentional actions by external people aimed at Software Development External causing a disruption or damage of the physical components or facilities SDLC infrastructure

Software components

Software Deployment

Maintenance

Data

Theft of

Theft of information or IT assets that support the equipment SDLC infrastructure development process

(hardware)

Software Components

Software Deployment Incidents such device thefts, bomb attacks,

Physical damage

Physical Attack vandalism or sabotage could damage the SDLC infrastructure

to equipment

equipment Maintenance

Vandalism and

theft Software Deployment Intentional attacks on development process Modification of SDLC infrastructure support (servers, laptops, mobile) of development

equipment/

software, dependencies thereof, and on IoT Software Development

devices

devices that are closer to the physical process. Maintenance

Theft of documents from private company Data

Theft of

archives, often for the purpose of re-sale or to

documents

obtain personal benefits. Maintenance

Stealing media devices on which copies of Data

Theft of backups

essential information are kept. Maintenance

Data

Attack based on the collection of information SDLC infrastructure Side-channel about what the system does when performing Software components attacks cryptographic operations to reverse-engineer it instead of on cryptographic weaknesses. Software Deployment

Maintenance

Attacks with physical access

Data

Theft or data tampering by an attacker leveraging SDLC infrastructure Radio Frequency the vulnerabilities of Radio Frequency (RF) Software components attacks communications in order to access facilities or physical components. Software Deployment

Maintenance

34 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

Data

Attacks that could involve the modification of SDLC infrastructure messages, identity theft, repudiation, data

Communication

analysis, etc. when a communication among Software components

layer attacks

different entities is performed with the aim of Software Deployment accessing facilities or physical components.

Maintenance

Data

Unauthorised SDLC infrastructure

physical access / Unapproved access to facilities that could be Forced Access Software components Unauthorised leveraged for malicious actions.

entry to premises Software Deployment

Maintenance

Lack of

Threat of financial or legal penalties or loss of Human Factor

Violation of rules compliance with

trust of customers and collaborators due to a and regulations applicable Data violation of applicable law or regulations.

regulations

Lack of

Lack of compliance with international standards compliance with Human Factor Breach of and Best Practices (e.g. BSA, ISO, CSA, NIST,

applicable

Legal legislation etc.) applied to the Software Development Data

legislative

Process introducing known failures in the system.

framework

Human Factor

Improper / The lack of specific security clauses in provider Data

Contract

Incomplete use contracts means that there may not be Requirements Software Components of definition contractual obligations at service or product level.

Maintenance

Software Development

SDLC infrastructure Flaws or errors in the software programming or

Software bugs system that produce an incorrect or unexpected Software components

operation or result. Software Deployment

Maintenance

Software Development

SDLC infrastructure

Due to a failure in the configuration system, an Software Components

Configuration

attacker can leverage the vulnerability to launch exploits Software Deployment an attack on the system.

Maintenance

Failures/ Software Data

Malfunctions vulnerabilities

SDLC infrastructure

Software that is not up to date may trigger severe Software Components

Outdated risks for a software solution. Potential issues may Software Deployment software arise from vulnerabilities that are present in the

software dependencies, or legacy systems. Maintenance

Software Development

Data

Use of insecure communication protocols that an SDLC infrastructure

Insecure

attacker could leverage in order to cause a communication Software components malfunction of the system or capture sensitive

protocols

information. Software Deployment

Maintenance

35 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

Software Components

Software Deployment Software that is obsolete and presents a Legacy software vulnerability due to a lack of support, updates or Maintenance patches. Software Development

SDLC infrastructure

Human Factor

Failure of

Software Design development These kind of failures can stop the development environment, process, or delay it, or bring about a loss of Software Development tools or control over it. Software Deployment

processes

Maintenance

Data

Issues in the testing environment could affect the Failure of testing Software Development veracity of testing results (not tested correctly, not

environment,

tested uniformly, etc.), or may make it impossible SDLC infrastructure

tools or

to carry out some tests, stopping or delaying the processes Software components development process.

Software Deployment

Software Development

Failure of The integration phase is critical, since all software Data integration pieces are put together to ensure they work as environment, expected. If potential issues arise, they may result Software Components tools or in software integration issues or bad results in SDLC infrastructure processes integration testing.

Software Deployment

Software Development The production environment is critical because it

Failure of

is the real scenario to work with. Failures can Data

production

affect the availability of the whole solution, as well environment, Software Components SDLC process as the way to measure or control how software

tools or

failures behaves. It also may result in a leakage of Software Deployment

processes

sensitive information due to errors. SDLC infrastructure

Data

SDLC infrastructure The ratio of false negatives in the security tools is

False Negatives

too high to rely on the results. Software Development

Software Deployment

Software Development

The security tools are too complex, leading to Software Design Complexity their incorrect use and results that are difficult to interpret. SDLC infrastructure

Software Deployment

Data The tool does not analyse the full project or the Incomplete tool is used when the software is not finished, SDLC infrastructure

Analysis leaving parts of the software unanalysed from the Software Development point of view of security. Software Deployment

Data Either the means by which the results are presented or the high volume of false positives SDLC infrastructure

Noisy Results

make the results hard to process, causing Software Development vulnerabilities that may go unnoticed. Software Deployment

36 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

Data

SDLC infrastructure Failure of In the design phase, security requirements are Maintenance software design included in the solution as design features. environments, Potential failures at this point can lead many Software Design tools or vulnerabilities to go unnoticed during following Software Development processes stages of development. Software components

Software Deployment

Software Development

Establishing security requirements that are not Data Inadequate appropriate for the solution or for the development Software Design requirements process can lead to the emergence of vulnerabilities. Software Components

Software Deployment

Software Design

A failure of a service such as the programming of SDLC infrastructure Internal service a code part or component design that has been Software components provider developed by IT departments/service providers within an organisation Software Deployment

Maintenance

SDLC infrastructure

A failure of a service that is supported by a cloud Software Components

Cloud service

provider, such as an application through the provider Software Deployment Internet (SaaS). Third party Maintenance

failures

SDLC infrastructure

A failure or unexpected result of any part that has Software Components Other provider been outsourced and whose operation has an impact on software development. Software Deployment

Maintenance

SDLC infrastructure It is necessary to adopt risk management for Software Components Third-party these assets. These risks must be mitigated to libraries prevent various types of threats from being Software Deployment executed. Maintenance

Contractual requirements for software providers can manage many different aspects, such as how Human Factor software is developed, when it has to be delivered, security in workstations of developers, Software Design Software how to deliver the software, security maturity of SDLC infrastructure providers the software, maintenance of the software, etc. In case of failure, it may have severe consequences, Software components Failure to meet such as intellectual property loss, inability to contractual provide software when needed, immature security Maintenance requirements (e.g. for the software delivered, etc.

software maintenance)

Many different aspects can be included in the Human Factor contract, and they depend on the component that Software components they provide. SDLC may be impacted if

Component

components are not needed, stopping or delaying SDLC infrastructure

suppliers

the process, or not providing the functionalities Software Deployment that they need, or lacking maintenance when it is required (SLAs) Maintenance

37 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

Security is an aspect to consider globally in an Human Factor

organisation, and any organisation provider may result in security issues such as an information Software Deployment

rd leakage or damage to information integrity, if Other 3 parties Software Components security clauses of the contract are not correctly

followed (for instance, cleaning service staff may Maintenance

expose sensitive information when they manage an organisation's residues) SDLC infrastructure

New updates (new software versions) need to be Software Deployment tested thoroughly to ensure that they not impact

Insecure

the properties of the software. Insecure updates Maintenance

software updates

can make a software that was safe in the previous Software Components version vulnerable.

Maintenance failures

The process to update software is not secure

Insecure enough (hardcoded credentials for maintenance, Software Deployment

software update backdoors, integrity is not checked), allowing process potential attackers to compromise the software by Maintenance

abusing the updating process.

In this case, the objective is to manipulate the

data in order to modify data, cause the failure of

Abuse of personal Data the software, or acquire monetary gains. By Data data Manipulation accessing the operation data of the system, an

attacker may modify them to alter the operation of

the application for malicious purposes

Software Deployment

Improper / Abuse of authorised access systems that support SDLC infrastructure

Incomplete use the infrastructure, making it possible to modify the Software Development /abuse access to version of the software and the tools during the

IT systems process of software, Data

Maintenance

Software Deployment

Threat of unauthorised manipulation of hardware Unauthorised Software Development and software that can be used to modify source

installation of

code for malicious purposes, posing threats such SDLC infrastructure

software/

as bomb injections, backdoor generation, or the hardware Software components destruction of source code.

Nefarious Abuse of Maintenance

activity/ Abuse authorisation

Data

Software Development An unauthorised modification of configuration Unauthorised SDLC infrastructure data could cause the system to work incorrectly or

use of devices

the security measures implemented may not act Software components

and systems

correctly, allowing attacks against the system. Software Deployment

Maintenance

Unauthorised modification of code or data, Data attacking its integrity. In this case, it can result in

Unauthorised

the manipulation of information, unauthorised Software Development

access to data

access to confidential information, and access to Software components source code.

Software Components

Source code

Unauthorised modification of source code for exploits (e.g. Software Development Software malicious purposes such as bomb injections,

third-party

exploitation backdoor generation, or the destruction of source Data

libraries

code.

exploitation)

Maintenance

38 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

Software Components The default configuration is vulnerable, containing Configuration weak/default passwords, software bugs, and Software Deployment

exploits configuration errors. This threat is usually Maintenance connected to others, like exploit kits Data

Threat leveraging the use of default configuration Software Deployment of the testing environment, with default Testing exploits SDLC infrastructure passwords, software bugs, and configuration errors. Software Components

Software Deployment Threats leveraging the use of outdated software versions, bugs, improper configurations, zero-day SDLC infrastructure

Production

vulnerabilities or specific software components, exploits Maintenance such as weak cryptographic algorithms or vulnerable open source libraries Software Components

Data

Human Factor

Software Design In Advanced Persistent Threat (APT) attacks, eavesdropping and information gathering Software Development

Advanced

comprise one of the first stages carried out in Persistent Threat SDLC infrastructure order to identify weak spots and potential entry/attack points Software components

Software Deployment

Maintenance

Exploit Kit Code designed to take advantage of a Software Deployment Malware (virus, vulnerability in order to gain access to a system. SDLC infrastructure Trojans, This threat is difficult to detect and during the ransomware, software development process its impact ranges Software components exploit kits) from high to crucial, depending on the assets affected Maintenance

Threat of unauthorised manipulation of development environment, tools or processes to Manipulation of intentionally manipulate the information systems Software Development development or review process of the development to cover environment, other nefarious activities (false results, Maintenance tools or modification of the information, information SDLC infrastructure processes integrity loss, no testing updates), or to obtain information about the software under development (intellectual property, etc.)

Unauthorised modification of testing elements (environment, processes, tools) with malicious Software Development

Manipulation of intentions (modifying test results, obtaining Maintenance testing intellectual property or other sensitive information, environment, etc.). For instance, an attacker could modify the Software Deployment Manipulation of tools or test data in order to allow a system that has not SDLC SDLC infrastructure processes passed the security tests to be accepted and infrastructure continue to the production phase with security flaws

Software Development

Manipulation of

Threats that aim to modify the integration integration Maintenance environment to obtain intellectual property (the

environment,

whole solution), or modify the results of the tests tools or Software Deployment when all software components are put together.

processes

SDLC infrastructure

Manipulation of Production environment is critical because it is the Software Development production real scenario to work with. Malicious modifications environment, can affect the availability of the IoT solution, as Maintenance tools or well as the way to measure or control how software behaves (try to cover other malicious Software Deployment

processes

activities). It may also have severe effects, for

39 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

instance providing access to sensitive information SDLC infrastructure

(personal data, code, configuration data,

operation data, etc.), or modifying it.

Unauthorised manipulation of hardware elements Maintenance of the solution, affecting the integrity of hardware

Manipulation of

elements (which are the basis of the rest of Software Deployment

hardware

technologies: infrastructure technologies, support SDLC infrastructure systems, etc.)

Threat of unauthorised manipulation of software

Manipulation of

update environment Patched the lack of a formal Maintenance

software update

update management procedure entails that the environment, Software Deployment urgency of fixing an application or system may

tools or

bring about errors that cause vulnerabilities in the SDLC infrastructure

processes

system.

Threat of manipulation of data repositories with Data the objective of manipulating source code for

Manipulation of

malicious purposes such as bomb injections, Maintenance

data repositories

backdoor generation, or the destruction of source Software components code.

Understanding IT infrastructure as the set of

technologies that provide the needed environment Maintenance (networks, operating systems, etc.) for the

SDLC

systems and applications, these threats aim to Software Development

infrastructure

make them unavailable, affecting all technologies SDLC infrastructure that need them. It can have severe

consequences.

Maintenance

Threats that aim to compromise the availability of Denial of Service SDLC support all type of systems and middleware that sustain SDLC infrastructure

systems the software development process, stopping or Software components

delaying the development process.

Software Deployment

When an environment is not available due to Maintenance

Development/

malicious activities, the development process may testing/ Software Deployment be stopped or delayed (tests cannot be

integration/

performed, etc.). In the case of the production Software Development

production

environment, the availability of the IoT solution

environments

may be partially or completely impacted. SDLC infrastructure

Unauthorised modification of source code for Software Components

Source code (e.g.

malicious purposes such as bomb injections, tampering, logic Maintenance backdoor generation, or the destruction of source

bombs, etc.)

code. Data

The unauthorised modification of this type of data Data

Configuration may result in an alteration of software Software Deployment data parameters, which can affect the security of the

solution (disabling security measures, etc.). Maintenance

Manipulation of

information Threat of intentional manipulation of test data with

the objective to modify the test data in order to Data

Test data allow a system that has not passed the security

tests to be accepted and continue to the Maintenance

production phase with security flaws.

Threat of intentional manipulation of deployment

data. A lack of an adequate testing environment Data

Deployment data affects the validity of the security tests, since the environment should be as similar to production as Software Deployment

possible.

40 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

Not adequately protecting backups could allow an Data Backup Data attacker to access and modify or destroy data, Maintenance Modification compromising the system's operation in the event of a failure if access to the backups is required. Software Deployment

Data

Poisoning Training data tampering could cause a diversion Software Development training / testing from expected data, highly impacting the final data results of the SDLC process. Software Deployment

Maintenance

Threat of an e-mail fraud method in which the perpetrator sends out legitimate-looking email in an attempt to gather personal and financial

Phishing

information from recipients. Typically, the

(whaling, vishing,

messages appear to come from well-known and Human Factor

spearphishing,

trustworthy Web sites. The main object in this

etc.)

case it is obtain information of the member of the team development and get identify, passwords and could be modification of the source code

Social engineering

A reverse social engineering attack is a person- Reverse social to-person attack in which an attacker convinces Human Factor engineering the victim that he/she has or will have a problem, and the attacker is the key to solve it.

It is a technique to drive the victim into a trap by resorting to his/her curiosity and interest (like Baiting Human Factor putting rouge USBs on the floor of a parking area).

This threat aims to steal the identity of a Identity Fraud/ legitimate user of the system to perform actions Identity theft Human Factor Account on behalf of the original user, or to access information that the user can access.

Source code is one of the most important assets for a software development project. It is an investment of the organisation in creating Software Components Source code technology. A loss of confidentiality regarding this Maintenance disclosure asset may have severe consequences for the organisation due to an intellectual property loss, Data and potential attackers can discover security holes while reviewing code.

Configuration data is an important type of data Data Configuration where many parameters of the software are Maintenance data disclosure defined, as well as data about connections to other systems. Software Deployment

Test data contain sensitive information about the system and its status (current and past), since Damage/ Loss Disclosure these data are composed of results of the Data

Testing data

different tests done, including security tests. This

disclosure

information is confidential, and an unauthorised SDLC infrastructure access may have severe consequences for the software, as well as for the organisation.

Production data is an important asset that is quite Data valuable for the organisation. If these data are

Production data

exposed in any way, sensitive information can be Software Deployment

disclosure

compromised (personal information, intellectual Maintenance property).

Third-party components that are part of the Data solution are as important as your own. The Third-Party information they hold may be accessed by SDLC infrastructure unauthorised individuals if the third party does not Software Components observe due diligence.

41 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

Software Deployment

Maintenance

Data An unauthorised access to backup data may Backup Data expose sensitive information, intellectual property, Software Deployment etc. Maintenance

Source code is one of the most important assets for a software development project, it is an investment of the organisation for the creation of technology. For proprietary software, a loss of confidentiality regarding this asset may have Data severe consequences for the organisation due to Source code an intellectual property loss. Moreover, potential Maintenance attackers may discover security holes by Software Components reviewing code. In the case of a loss of source code, the company will lose efforts and resources. It would need new resources (equal or more than in the previous situation) to be at the same point as it was.

Configuration data is an important type of data where many parameters of the software are Data defined, as well as data about connections to

Configuration

other systems. A loss of these data may affect Maintenance

data

internal system connections or may cause any Software Deployment other issue affecting the availability of the solution.

Test data contain sensitive information about the system and its status (current and pasts), as these data are composed of results of the different tests done, including security tests. This Data Test data information is confidential and an unauthorised access may have severe consequences for the SDLC infrastructure software, as well as for the organisation. Its loss represents a loss of the technological memory of Loss/leakage of the organisation.

information

Production data is an important asset that is quite valuable for the organisation. If these data are exposed in any way, sensitive information may be Data compromised (personal information, intellectual Production data Software Deployment property). A loss of this kind of data may have a severe impact on the daily operations of the Maintenance organisation, and possibly make it difficult to continue with regular operations.

Software Design Documentation is a valuable asset that contains information about processes, software, designs, Software Development etc. In general, private information can have SDLC infrastructure negative consequences for the organisation if

Documentation

these data are accessed by unauthorised parties. Software components A loss of documentation or a failure to document changes to it represents a loss of knowledge for Software Deployment the organisation. Maintenance

Backup data are as critical as operation data, since it is the main means to restore operations in Data the event of an issue. If these data were leaked, Backup Data Software Deployment the impact might be even greater than that of a leakage of operation data, since it may also entail Maintenance the leakage of all history data.

A security breach in a service provider on which Data Third-Party the project depends exposes sensitive information about its own system. This endangers sensitive SDLC infrastructure data, such as data about its operation, personal

42 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

data of users, test reports, intellectual property, Software Components etc. Software Deployment Maintenance

Data Training all personnel is essential to ensure that Software Design the development process is addressed in a correct manner. A data modification or leakage Software Development Training data could be leveraged by an attacker to cause an interruption of the SDLC process or to obtain Software components sensitive information about security to perform Software Deployment reverse engineering. Maintenance

3.3 EXAMPLES OF ATTACK SCENARIOS The different cases presented here are examples of potential scenarios that can affect IoT software development. Taking into account the overall picture of IoT applications previously discussed (embedded devices, communications and cloud services), each scenario focuses on one of these three elements. These use cases show a high-level overview of different attacks, whereby it should be clarified that they serve only as indicative illustrative cases. 3.3.1 Insecure Credentials in Embedded Devices One of the most critical issues in relation to IoT solutions is the use of default or insecure credentials. Many such solutions impose hardcoded passwords that cannot or do not need to be changed, or do not include mechanisms to ensure the use of secure authentication. This means that oftentimes a user lacking sufficient awareness of security may choose to use default credentials or create weak ones on their IoT solutions simply because they are easier to remember. Even when there is a certain level of awareness, traditional restrictions (such as password length restrictions or character use impositions) often lead to exasperation or annoyance on the part of users, who opt to use insecure passwords to overcome these abrasive burdens. In turn, an attacker might be able to scan the exposed devices using resources like Shodan and other tools (e.g. insecam.org or online databases containing exposed or default credentials to different solutions). The attacker would eventually be able to determine, by means of testing, if the solution lacks a password or uses a default or weak one, thus taking control of the device to gain further privileges and, ultimately, use it for malicious purposes, such as creating botnets (one famous example would be Mirai). These botnets are often used to launch Distributed Denial of Service (DDoS) and cryptojacking attacks on other networks, among others. Such attacks can be prevented by means of different measures throughout the SDLC process, and essentially entails ensuring that such weak of guessable credentials cannot be used in the solution. For instance, it should be impossible to preserve default credentials after initialization of the IoT product, and users should be provided with guidelines on how to create secure ones. When it comes to creating safe passwords, first of all, it is necessary to use strong authentication mechanisms (for example, based on challenge-response authentication, with an SSH signature) whenever possible. Additionally, it is also important to ensure that the authentication mechanism prevents users from creating weak credentials (such as keywalk passwords, that is, passwords based on adjacent keyboard keys, e.g. ‘qwertyuiop’, or obvious 43 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

ones, like ‘Aa12345!’). There are plenty of international authorities that have created guidelines for this purpose, but essentially, users should be given freedom to be creative and create custom passwords that are both secure and user-friendly, without too many format restrictions. Online databases of exposed or default credentials are a good resource to avoid the use of weak authentication mechanisms. This would hinder the malicious actions of the attacker, since the tools available would be less effective to guess weak or default passwords. Another recommendation is to implement security mechanisms like multiple-factor authentication during the SDLC or mechanisms forcing to change or set up a new password before using the device for the first time. On a similar note, in order to address publicly exposed services and harden the available services, it would be necessary to reduce service to the minimum and remove all unnecessary functions/services/libraries. Figure 5: Attack 1 – Insecure Credentials in Embedded Devices 44 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

Table 3: Insecure Credentials in Embedded Devices Threats Assets Affected

 Software Component  Data

Personnel: Insider threat; Incompetent / Inexperienced /

 Software Development Tools

Demotivated Staff; Absence of personnel / Limited

 Software Deployment

resources.

 Maintenance  Human Factor

 Software Development Tools  Data Unintentional damages: Unintentional modifications;  Software Components Erroneous use or administration of devices and systems.  Software Deployment  Human Factor  Maintenance

 Software Development Tools  Data

Failure / Malfunctions: SDLC infrastructure failures;

 Software Components

Maintenance failures.

 Software Deployment  Human Factor

 Software Development Tools  Maintenance

Nefarious activity / abuse: Manipulation of SDLC

 Data

infrastructure; Manipulation of information.

 Software Deployment  Software Components

Prevention actions during SDLC phases

 Requirements: Make secure device and user authentication a formal security requirement.  Software Design: Include a mature authentication mechanism, and perform threat modelling as a security

exercise to detect potential issues.

 Development/Implementations: Build/implement the secure authentication design appropriately.  Testing & Acceptance: Test the software to detect potential issues and assess the results from the point of view

of security.

 Deployment & Integration: Ensure configuration errors or mistakes (software, infrastructure, and third-party

services) have been fixed to prevent deployment failures.

3.3.2 Lack of Flexibility to Secure Communications In this scenario, the security issue arises in relation to the use of rigid communication protocols and the software components that provide this functionality. This scenario especially affects IoT interfaces, where the software uses the communication functionalities to exchange information with other elements. These interfaces are mostly software-based, where the protocol and its corresponding options are used by the software. This issue arises in relation to the software development process, since flexibility is designed, implemented and configured during the creation of technology. Depending on this, the operation mode of the software may vary in the maintenance phase. In this regard, flexibility is a software decision that is present in the whole lifecycle of the software development. When it comes to real life, the problem of this scenario would materialise if an insufficiently flexible communication protocol prevents the user from applying additional security measures to communications or from changing to another new protocol that increases the security. Such an incompatibility could cause a security gap in the solution, rendering it vulnerable. 45 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

An attacker may detect this lack of security and try to compromise the communications, because if the type of communication used is obsolete, it will no longer be appropriate for the functionality of the system, as it uses insecure ecosystem interfaces or insecure data transfers and storage. The attacker might then use the insecure communication protocol in combination with different types of attacks (man-in-the-middle attacks, leakage of sensitive information, identity theft, etc.). Ultimately, the objective of the malicious user is to gain further privileges and to obtain sensitive information such as personal data, credit card information, authentication credentials, etc. This issue can be easily prevented by assessing and observing the necessary level of flexibility throughout the SDLC, making it a requirement for the solution. Figure 6: Attack 2 – Lack of Flexibility to Secure Communications Table 4: Lack of Flexibility to Secure Communications

Threats Assets Affected

 Software Deployment  Data Outage: Loss of support services; Communication issues  Software Components  Maintenance  Human Factor

 Software Development Tools  Data

Unintentional damages: Unintentional modifications;

 Software Components

Erroneous use or administration of devices and systems;

 Software Deployment

Damage caused by a third party

 Human Factor  Maintenance

 Human Factor  Data

Legal: Contract requirements

 Software Components  Maintenance

 Software Components Failure / Malfunctions: Third party failures; Failure to meet  Software Deployment contractual requirements; Maintenance failures  Maintenance  Human Factor

46 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

Prevention actions during SDLC phases

 Requirements: Establish the flexibility of software communications as a requirement.  Software Design: Perform a good design of the solution, and perform threat modelling as a security review to

detect potential issues.

 Development/Implementations: Choose a secure library, perform a secure implementation of the functionality,

and use peer code reviews to identify potential problems.

 Testing & Acceptance: Use Dynamic Application Security Testing - DAST (see Annex D) to detect insecure

communications.

 Deployment & Integration: Perform hardening activities.  Maintenance & Disposal: If a communication mechanism is secured during deployment but, later on, it proves

to be vulnerable, the lack of flexibility makes it impossible to solve this issue easily. This issue can be addressed with flexibility to secure communication by patches / software updates.

3.3.3 Insecure Software Dependencies in Cloud Services As previously studied by ENISA cloud services are developed using software components (dependencies) already available, to reduce development time. These components (usually from third parties) are as important as the code developed by the project team (in terms of security). They are usually software frameworks or libraries that provide common functionalities to the software, of the same nature regardless of the business logic. If a dependency is vulnerable and exposed on the Internet, there may be severe consequences. Successful attacks based on outdated components are clear indicators that software dependencies should be taken seriously. Cloud services could be affected in a similar way. For example, a developer or organisation may not ensure that the dependencies used for a solution are not vulnerable. Even if they do verify this, they may not keep track of new vulnerabilities detected over time in order to ensure prompt patching. If an attacker is aware of this negligence, he or she may study the endpoints exposed for such IoT solution. Analysing the underlying technologies of this endpoint (producing errors, responses, etc.), the attacker may be able to detect dependencies and versions. This means that, ultimately, simply by checking public vulnerabilities for the dependencies exposed, the attacker may find one to exploit. If such a vulnerability is detected, the malicious agent could then take advantage of it to launch, for example, an unrestricted file upload. The impact of such attack is high, supposed code can be executed in the server context or on the client side remotely, gaining access to the solution, and potentially obtaining sensitive or confidential data. This type of issue might have been easily prevented, had the organisation behind the solution ensured the use of vulnerability-free components for development, and periodically reviewed their security and applied patches and updates accordingly during the SDLC. The integrity of the cloud service reflects the security of the components it comprises; one vulnerable dependency may compromise the entire solution. In this context, it is important to implementing, for important/critical business functionalities, end-to-end security mechanisms to mitigate this risk. 47 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

Figure 7: Attack 3 – Insecure Software Dependencies in Cloud Services Table 5: Insecure Software Dependencies in Cloud Services Threats Assets Affected

Personnel: Incompetent / Inexperienced / Demotivated

 Human factor

Staff

 Software Components

Failure / Malfunctions: Outdated software; Third party

 Software Deployment

failures

 Maintenance

Prevention actions during SDLC phases

 Requirements: Establish software component dependency analysis against CVE feeds as a security

requirement.

 Development/Implementations: When selecting a FOSS dependency, assess if the community behind it takes

security seriously, and if it is big enough to ensure that the software is not discontinued.

 Testing & Acceptance: Perform software composition analyses to detect potential problems with software

components using SAST and DAST.

 Deployment & Integration: Test the different software artefacts of the cloud service, as well as their

corresponding dependencies. Do not put risky dependencies in the production environment when software is going to be deployed, especially for software that is exposed to the Internet.

 Maintenance & Disposal: Monitor software dependencies periodically to detect new vulnerabilities prior to the

cloud services being deployed into the production environment.

48 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

4. GOOD PRACTICES FOR SECURE IOT SDLC

4.1 SECURITY CONSIDERATIONS One of the most significant objectives of this document is to address the main security considerations to take into account during the SDLC. During the execution of this study, a group of experts was asked about the main challenges that they have to overcome in order to provide greater security during IoT SDLC. As a result of this consultation, a non-exhaustive list of security considerations is shown in Table 6. Table 6: Security considerations

Phases Security considerations Description

Identification of security requirements according to data classification,

Security Requirements

business requirements and legislative or standardisation objectives.

Alignment of security requirements with hardware limitations taking into

Hardware limitations

consideration additional aspects resulting from software requirements.

Analysis and requirements

Identification of the appropriate protocols for the solution, taking into

Protocols

account its security features and the IoT solution’s security requirements.

Application of threat modelling methodologies to identify the software

Threat modelling

threats and the associated countermeasures to mitigate them.

Identification of the IoT solution’s attack surface by taking into

Attack surface analysis

consideration architecture aspects and utilising security user stories.

Software design

Use / application of secure design patterns and principles. Security

Secure design

architectures determine when and where to apply them.

Use of known security guidelines to ease the implementation of security Frameworks controls during the software development process in order to enhance security throughout the software lifecycle.

Use of trusted security libraries when third-party resources are used, Libraries ensuring that they are widely tested based on certain security criteria so as to not compromise the software.

Development / OS as well as communication protocols come with built-in security Implementation Built-in Security functions which can be leveraged to implement security features in applications.

Use of the Secure Code guidelines and standards to alleviate from most

Guidelines

common application layer vulnerabilities.

Use of mechanisms to ensure that external libraries, tools or APIs used External checks during the SDLC phases such as development, deployment and maintenance are proven, secure and updated.

49 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

Activities aimed at verifying that the design used follows the specifications

Design review

defined during the design stage so that all security requirements are met

Review of the code/quality of the code, preferably using automated tools in

Code verification

order to look for errors introduced in the implementation phase.

Testing / Acceptance

Performance of security tests to ensure that software is free of known

Security requirement tests

vulnerabilities and to detect risks related to security requirements.

Testing to identify potential vulnerabilities that could exist in IoT solutions

Penetration tests

and could be exploited by an attacker.

Secure the environment adding protection layers as a part of the in-depth

Hardening environment

defence strategy in order to reduce the system’s attack surface.

Use of the control activities to guarantee an artefact’s quality, monitoring

Deployment / Configuration and

and controlling changes made during the development lifecycle, and

Integration Vulnerability management

identifying and repairing potential flaws affecting the software.

Definition of the procedure to document, monitor and track all changes that

Change management

may be made in the software development process

Procedure to address the steps to be taken in order to ensure a normal

Incident management

operation when a security issue takes place in the SDLC process.

Management of the end of Secure management process of software components, artefacts and data

Maintenance /

life-disposal once the IoT solution is going to be retired from production.

Disposal

Delivery management to push new versions of software in a remote Remote SW updates environment securely when it is necessary to apply an update, either to add new functionalities or to mitigate vulnerabilities.

4.2 GOOD PRACTICES Development of security measures for the IoT SDLC is one of the key objectives of this report. The aim is to provide guidelines and recommendations for the target audience to assist in countering and mitigating the threats that might impact IoT SDLC. Firstly, extensive desktop research was conducted. Thorough analysis of relevant sources (listed in Annex C) allowed distinguishing frequently mentioned topics in IoT SDLC security. These topics were then aggregated to create an initial list of security domains. Final set of domains was clarified and adapted based on the interviews conducted with the stakeholders resulting in a list of 16 domains that provide a comprehensive view of the Secure IoT SDLC landscape and indicate areas that require protection. To organise the domains in a logical manner, they were classified into three main groups:  People: security considerations that affect all stakeholders involved in the life cycle of IoT solutions, from the software developers, to the end users of the product.  Processes: secure development addresses security in the process of software development when a software project is conceived, initiated, developed, and brought to market.  Technologies: technical measures and elements used in order to reduce vulnerabilities and flaws during the software development process. Measures included in this section provide a short description but further details and a mapping with the threats and the corresponding references to back up each measure may be found in Annex A. 50 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

Figure 8: Security measures 4.2.1 People 4.2.1.1 Training and Awareness  PE-01. Define a corporate strategy for specific security training: Ensure that all personnel participate in awareness-raising activities and training, focusing on the responsibilities of each role in applying security throughout the customised development process.  PE-02. Promote security awareness at all organisation levels: Ensure that the entire organisation structure is made aware of the importance of safeguarding security from the first stages of development, including decision-makers.  PE-03. Assess the security skills to be updated: Assess the internal security knowledge of the organisation to determine if the resources are aligned with the latest security advances by means of activities, exams, certifications, etc.  PE-04. Allocate resources to stay up to date with security topics: Stay up to date with the latest industry trends as technology progresses in order to anticipate increasing risks and be prepared to face any new threats that may arise. 4.2.1.2 Roles and Privileges  PE-05. Establish security roles and privileges within the development project: Define roles and responsibilities within the process so that the minimum sufficient level of privilege for each duty can be identified and assigned to the relevant person.  PE-06. Implement a separation of duties in the work team: Carry out a segregation of duties in order to enable the collusion-resistant processes in SDLC and to minimise the risk exposure of its processes.  PE-07. Protect the process against privilege abuse: Implement security controls to prevent the SLDC process from being compromised by any user with legitimate rights.  PE-08. Allocate resources for process monitoring: Propose improvements to ensure that a problem during SDLC process can not cause an interruption of business continuity. 51 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

 PE-09. Designate a physical security officer: As a part of SDLC process, the physical facilities must be correctly protected and veiled by a security responsible. 4.2.1.3 Security Culture  PE-10. Establish governance and controls for critical security know-how: Allocate efforts to ensure that certain critical skills stay at company by means of promotions, rewards, etc.  PE-11. Consult with security experts to improve the process: Define a roadmap of new actions to be carried out in order to improve or complete the development process.  PE-12. Designate a Security Champion figure: Centralize all security related aspects security in a cross-functional profile. This figure must manage all security topics during the SDLC.  PE-13. Monitor and respond to the supporting security incidents: Security is not absolute and risks can materialise. Allocate resources to ensure the correct performance of SDLC support infrastructure. 4.2.2 Processes 4.2.2.1 Third-Party Management  PR-01. Implement a Supply chain management plan: Ensure the integrity of the supply chain with a plan containing security frameworks, risk management, contract guidelines, etc.  PR-02. Assess the software dependency process: Properly manage third parties and dependencies by means of risk management and security requirements.  PR-03. Test the Third Party process: Define a process to test the security of all third party components prior to integration.  PR-04. Verify Third Party software and services: Ensure that all third-party components meet the security and contract requirements stipulated.  PR-05. Disseminate a communication procedure to request external support: Ensure that the whole organisation is informed of how to proceed if support is required from third-parties.  PR-06. Protect data against leakages: Specify confidentiality clauses in order to prevent and avoid sensible data disclosures.  PR-07. Contractually require controlling and monitoring the external services through KPI's: Apply controls to guarantee that external stakeholders involved in the SDLC process implement security into its processes. 4.2.2.2 Operations Management  PR-08. Define an Incident Management Plan: Define a plan to manage vulnerabilities and updates, including for third-party components, with the necessary roles, responsibilities and activities to effectively respond to security incidents during development.  PR-09. Define a Change Management Plan: Define a plan to manage changes to the development process with an informed view of the associated impact on the budget, schedule, scope, communication and resources.  PR-10. Implement Vulnerability and Patch Management: Define a plan to manage vulnerabilities and updates during development, in a manner informed to the associated impact upon the security assurances attainable by the SDLC outcome.  PR-11. Implement Configuration Management: Adequately manage the integrity of the system by ensuring that no unauthorised changes are made to the configuration. 52 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

4.2.2.3 SDLC Methodology  PR-12. Establish a Control Access and Authorisation Policy: Define a privilegebased scheme to prevent unauthorised users from accessing restricted resources.  PR-13. Automate the SDLC process: Automate processes supported by tested tools to reduce costs, human efforts and errors.  PR-14. Define Security Metrics: Define, implement, and monitor security metrics to ensure fulfilment of the security requirements throughout lifecycle.  PR-15. Adopt a Maturity model: Adopt a maturity model to improve security best practices during software development.  PR-16. Define and document the SDLC process: Define a guide identifying security best practices and testing in each phase of SDLC. In addition, document a secure development process with security requirements and development guides and update it regularly based on the impact and criticality of newly discovered vulnerabilities. 4.2.2.4 Secure Deployment  PR-17. Define a disposal strategy: Define a plan to dispose of the solution and all its data and components adequately at the end of the lifecycle.  PR-18. Establish process for SDLC vulnerabilities follow-up, monitoring and updates: As threats progress, new vulnerabilities can affect the SDLC process. Perform a procedure to be updated is crucial for so as not to incur emerging issues.  PR-19. Implement a testing strategy: Leverage automatic tools to ensure that minor errors are eliminated.  PR-20. Define a secure deployment strategy: Establish a procedure for the deployment steps and ensure all stakeholders follow it. 4.2.2.5 Security Design  PR-21. Provide a secure framework: Define a framework to implement security by design throughout the lifecycle of the solution.  PR-22. Apply least privilege principle: Allocate only the user privileges required to perform the necessary operations of each role in the solution.  PR-23. Verify security controls: Verify that the security controls implemented are reusable, sufficient, effective, reliable, audited, managed, and governed.  PR-24. Perform a design review: Review the security of design periodically throughout development to ensure requirements are met and identify the attack surface.  PR-25. Specify security requirements: Identify security requirements prior to development to implement features that ensure regulatory compliance and avoid vulnerabilities throughout the process.  PR-26. Perform risk assessment: Identify risks throughout the software development process, analysing the sources, data storage, applications or third parties.  PR-27. Implement Threat Modelling: Identify security objectives and define a threat model to implement countermeasures from the early stages of SDLC. Ensure that the threat modelling process is notified of changes by integrating its communication channel to that of the change management process.  PR-28. Implement Data classification: Classify data based on their level of sensitivity to establish protection measures accordingly.  PR-29. Ensure that the hardware requirements derived from software requirements are considered: Define and document requirements stemming from hardware, namely requirements that the software needs to meet in order to be consistently deployed on the targeted hardware. 53 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

4.2.2.6 Internal Policies  PR-30. Establish a communication plan for security measures: Develop a communication plan to ensure that the whole organisation is informed about security considerations: security policies, security procedures, new updates, etc.  PR-31. Control the process against information disclosure: Implement security controls to prevent any disclosure of information about security in the process that may compromise it.  PR-32. Verify and ensure the availability of updated security documents: Periodically verify that the organisation’s security documentation is available, updated, not tampered with, and strictly relevant to the matter of concern.  PR-33. Plan an alternative for unavailability cases: Resources are not for all time and unavailability times can come up, plan and have a second option is essential. 4.2.3 Technologies 4.2.3.1 Access Control  TC-01. Implement authorisation: Implement access control in IoT systems (and other underlying infrastructure) to ensure that the system verifies that users and applications have the right permissions.  TC-02. Secure storage of users' credentials: Ensure that user credentials of IoT systems (and other underlying infrastructure) are protected from disclosure (e.g. using hash functions to store passwords, centralising password storage, using hardware with TPM, etc.).  TC-03. Deploy physical protection for systems: Deploy security measures to prevent physical damages (intentional and unintentional) to IoT systems (and other underlying infrastructure).  TC-04. Implement key management and authentication mechanisms (e.g. FIDO): Ensure that SDLC systems' service credentials are stored securely (not accessible for non-authorised parties) for those systems that need to use (e.g. using a secrets vaults).  TC-05. Control the physical access to the critical facilities: Information cannot be accessible by any resource thus it must be protected against unauthorised access. 4.2.3.2 Third-Party Software  TC-06. Use libraries and third-party components that are patched for latest known vulnerabilities: Verify that software libraries and other frameworks to be included in the software development project are patched for the latest known vulnerabilities. Establish an upgrade roadmap for libraries and third-party components. In the context of fully developed third-party software, ensure that the manufacturer monitors databases (e.g. CVE) and notifies new vulnerabilities.  TC-07. Use known secure frameworks with long-term support: During the design, implement/develop and test the software under development, ensuring that the foundation technologies of the software will be maintained in the long term. 4.2.3.3 Secure Communication  TC-08. Use secure communication protocols: Ensure that communications cannot be compromised by using encrypted channels, integrity protection and authenticated connection to share information between IoT systems.  TC-09. Use proven encryption techniques: Protect data using encryption algorithms considered secure in any IoT systems and underlying infrastructure.  TC-10. Implement secure web interfaces: Any web interface, including openness (i.e. publicly accessible interface) or technologies of implementation (i.e. HTTP/HTTPS/QUIC stack), in use for IoT systems should require security in order to be used (authentication and authorisation check). 54 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

 TC-11. Secure session management: Due to the number of communications that take place in the IoT systems, many sessions are established between them. It is necessary to implement secure sessions in order to ensure security of communications. 4.2.3.4 Secure Code  TC-12. Implement secure coding practices: During the design, implement/develop and test the software under development, ensuring that an authentication mechanism referenced in globally accepted best practices is in place, that errors are handled correctly, that all input/output data are validated before accepting it, and that queries use parameterisation (or other equivalent security measure) to avoid code injections.  TC-13. Provide audit capability: During the design, implement/develop and test the software under development, ensuring that relevant security events are registered in software logs.  TC-14. Follow the principles of security by design and by default: During the design, implement/develop and test the software under development, ensuring that these principles are the foundation of the software.  TC-15. Implement software development techniques: Choose software development techniques (e.g. microservices) or architecture that produce clean and maintainable code.  TC-16. Verify production code: Ensure that the production environment is controlled and resources are securely utilised.  TC-17. Ensure security for patches and updates: Ensure that the SDLC model always allows for modification/patching/update of software in a secure fashion (tested, reviewed, etc.) before deploying any software change.  TC-18. Implement measures against rogue code and fraud detection: Deploy the countermeasures required in your SDLC process to detect potential rogue code in all relevant phases.  TC-19. Implement anti-tampering features: Deploy the countermeasures required in your SDLC process to prevent unauthorised code modification in all steps of the process. 4.2.3.5 Security Reviews  TC-20. Apply secure code review: Ensure that, in SDLC, the source code is reviewed in terms of security before accepting it.  TC-21. Perform an attack surface analysis: Ensure that, in SDLC, the attack surface is analysed and documented.  TC-22. Perform IoT SDLC tests: Ensure that throughout the SDLC, at least a penetration test is carried out when the software is complete. Additional testing should also be considered based on functional needs and risk assessment.  TC-23. Design a contingency plan: Ensure that the contingency plan is aligned with software development process in order to avoid an interruption during the SDLC phases.  TC-24. Monitor requirements to ensure the SDLC success: Implement a system to guarantee the requirement fulfilment. 4.2.3.6 Security of SDLC Infrastructure  TC-25. Ensure secure logging and implement monitoring: Ensure that logs of IoT systems and logs of the various tools used throughout the SDLC are stored in a secure place, and that they are constantly monitored.  TC-26. Implement physical detection systems: Implement a detection systems to control the state of the data hosting facilities (temperature, fire, etc.) to protect the SDLC support infrastructure against unavailability scenarios. 55 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

 TC-27. Define a mitigation plan for physical damages: Ensure that the possible risks that can affect and danger to the SDLC physical infrastructure are covered by a countermeasure in an action plan.  TC-28. Use whitelists for allowed applications: Control the applications that can be used by providing an authorised list and denying the rest.  TC-29. Audit the access to the SDLC infrastructure: Implement control systems based on logs in order to manage and track all accesses to physical and logical systems.  TC-30. Implement an identification protocol in your facilities: Provide personal and non-transferrable identification to all personnel, both internal and external. 4.2.3.7 Secure Implementation  TC-31. Enforce the change of default settings: Ensure change of default settings at first user interaction.  TC-32. Use substantiated underlying components: Restrict component customizations in order to avoid loss of security functionalities.  TC-33. Provide secure configuration options for end users: Ensure that end users have options to continuously improve security through the solution’s settings.  TC-34. Implement interoperability open standards: Implement interoperability open standards (e.g. OCF) to enhance secure integration processes.  TC-35. Enable devices to advertise their access and network functionality: By enabling devices to advertise their intended and supported functionality, the threat surface can be significantly reduced. An indicative practical example involves the use of IETF RFC 8520 on Manufacturer Usage Description Specification . 56 GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

A ANNEX: MAPPING OF SECURITY MEASURES

4.3 PEOPLE

SSDLC phases Security domain Title Description Threats Reference title involved

- CSA IoT Security Controls Framework. Cloud Security Alliance (CSA).

- Software Assurance Maturity Model (SAMM 1.5v). OWASP. Ensure that all personnel participate in awarenessraising activities and training, focusing on how to PERSONNEL REQUIREMENTS - Fundamental Practices for Secure apply security in a SDLC process. These activities UNINTENTIONAL DESIGN Software Development – PE-01. Define a must be customised depending on roles and DAMAGES DEVELOPMENT/IMP SAFECODE corporate strategy for responsibilities in the software lifecycle. Security (Accidental) LEMENTATION

Training and

knowledge must be a requirement before starting LEGAL TESTING AND - Systems and software engineering

Awareness specific security

any SDLC project. The training should include FAILURES / ACCEPTANCE - Software life cycle processes. ISO

training

information about best practices to ensure a safe MALFUNCTIONS DEPLOYMENT AND 12207 work environment, security roles and responsibilities NEFARIOUS INTEGRATION - BUILDING SECURITY IN within the project phases, and security tasks, as well ACTIVITY / ABUSE MAINTENANCE AND MATURIT Y MODEL (BSIMM). as security policies, standards, applicable DAMAGE / LOSS DISPOSAL BSIMM regulations and legislation. - MITIGATING THE RISK OF SOFTWARE VULNERABILITIES BY ADOPTING A SECURE SOFTWARE DEVELOPMENT FRAMEWORK (SSDF). NIST

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

- Information Security Management. ISO 27001

- Security for industrial automation and control systems. Part 4-1: Secure product development lifecycle requirements. IEC 62443- 4-1

- Recommended Security Controls for Federal Information Systems and Organizations. NIST 800-53

- The BSA Framework for Secure Software. BSA Software Alliance

- CSA IoT Security Controls Framework. Cloud Security Alliance (CSA).

- Secure Coding. Practical steps to defend your web apps. SANS.

Include security activities to raise awareness among - BUILDING SECURITY IN the employees (courses, simulations, talks, security MATURITY MODEL (BSIMM). REQUIREMENTS capsules via e-mail, round tables, etc.) about how to PERSONNEL BSIMM. DESIGN address security during the development process. If UNINTENTIONAL DEVELOPMENT/IMP - Software Assurance Maturity Model the entire organization is sensitised to security, it will DAMAGES LEMENTATION (SAMM). OWASP SAMM. Training and PE-02. Promote security be easier to implement the necessary measures to (Accidental) TESTING AND Awareness awareness at all achieve a process as secure as possible. These FAILURES / - Security Assurance in the SDLC for ACCEPTANCE organisation levels activities may be focused on different profiles: MALFUNCTIONS the Internet of Things. ISACA. DEPLOYMENT AND rewards depending on developers security training, NEFARIOUS INTEGRATION - IoT Security Maturity Model. promotion for specific project manager security ACTIVITY / ABUSE MAINTENANCE AND Industrial Internet Consortium (IIC). training, decision-makers security awareness by DAMAGE / LOSS DISPOSAL performing attack simulations (financial impact - Secure Software Development Life simulations), etc. Cycle Processes. CISA.

- THE DZONE GUIDE TO 2015 EDITION APPLICATION SECURITY. DZONE.

- The BSA Framework for Secure Software. BSA Software Alliance

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

- "Systems and software engineering -Software life cycle processes. ISO 12207"

- Security for industrial automation and control systems. Part 4-1: Secure product development lifecycle requirements. IEC 62443- 4-1

- Recommended Security Controls for Federal Information Systems and Organizations. NIST 800-53

- "Information technology - Security techniques - Information security management systems - Requirements. ISO 27001"

- "Information technology — Security techniques — Information security management systems — Requirements. ISO 27001" PERSONNEL An organisation must stay up to date with the latest UNINTENTIONAL - "Systems and software engineering security knowledge and certifications of its REQUIREMENTS DAMAGES employees. This assessment must be a matrix DESIGN - Software life cycle processes. ISO (Accidental) covering both specific and cross-cutting security DEVELOPMENT/IMP 12207" PHYSICAL ATTACK aspects by means of exams, the renewal of LEMENTATION Training and PE-03. Assess the certifications, internal assessments, training TESTING AND - Recommended Security Controls

Awareness security skills to be

providers in order to classify the staff by levels in LEGAL ACCEPTANCE for Federal Information Systems

updated

function of their security preparation and FAILURES / DEPLOYMENT AND and Organizations. NIST 800-53 background, thus making it possible to assign them MALFUNCTIONS INTEGRATION - Software Assurance Maturity Model specific tasks according to their level during the NEFARIOUS MAINTENANCE AND (SAMM). OWASP SAMM different SDLC phases. At least, once a year must ACTIVITY / ABUSE DISPOSAL be updated this information. DAMAGE / LOSS - Security for industrial automation and control systems. Part 4-1: Secure product development lifecycle requirements. IEC 62443- 4-1

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

- CSA IoT Security Controls

Framework. Cloud Security Alliance

(CSA).

- BUILDING SECURITY IN

MATURITY MODEL (BSIMM).

BSIMM. REQUIREMENTS Appoint resources and promote the implementation PERSONNEL DESIGN - Strategic Principles for Securing of monitoring, tracking and update activities by DEVELOPMENT/IMP the Internet of Things (IoT). U.S. means of threat intelligence in order to be aware of LEGAL LEMENTATION Department of Homeland Security. Training and PE-04. Allocate the status of current vulnerabilities and new types of FAILURES / TESTING AND Awareness resources to stay up to attacks that may affect your industry. Along with MALFUNCTIONS - Code of Practice for Consumer IoT ACCEPTANCE date with security topics security lessons learned, this information must be NEFARIOUS Security. UK. DEPLOYMENT AND centralised in an internal repository. The result of ACTIVITY / ABUSE INTEGRATION - "Systems and software engineering these tasks will help to prevent future security DAMAGE / LOSS MAINTENANCE AND -Software life cycle processes. ISO issues. DISPOSAL 12207"

- Recommended Security Controls

for Federal Information Systems

and Organizations. NIST 800-53

- GSMA IoT Security Assessment

Checklist - Reference CLP11_5

- The BSA Framework for Secure

Software. BSA Software Alliance.

REQUIREMENTS PERSONNEL - Systems and software engineering DESIGN UNINTENTIONAL — Software life cycle processes. Ensure that development teams work alongside DEVELOPMENT/IMP DAMAGES ISO 12207. PE-05. Establish security teams by means of the definition, LEMENTATION Roles and (Accidental) security roles and identification and allocation of functions, TESTING AND - MITIGATING THE RISK OF Privileges FAILURES / privileges within the responsibilities and tasks in relation to security in all ACCEPTANCE SOFTWARE VULNERABILITIES MALFUNCTIONS development project phases of development. This measure ensures that DEPLOYMENT AND BY ADOPTING A SECURE NEFARIOUS security is addressed when required. INTEGRATION SOFTWARE DEVELOPMENT ACTIVITY / ABUSE MAINTENANCE AND FRAMEWORK (SSDF). NIST. DAMAGE / LOSS DISPOSAL - Security for industrial automation

and control systems. Part 4-1:

Secure product development

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

lifecycle requirements. IEC 62443- 4-1. - CLASP Concepts – OWASP

- CSA IoT Security Controls Framework. Cloud Security Alliance (CSA)

- Software Assurance Maturity Model (SAMM 1.5v). OWASP

- Fundamental Practices for Secure Software Development, SAFECODE

- BUILDING SECURITY IN MATURITY MODEL (BSIMM). BSIMM

- Recommended Security Controls for Federal Information Systems and Organizations. NIST 800-53

- Security Design Principles. OWASP. PERSONNEL - CSA IoT Security Controls UNINTENTIONAL Framework. Cloud Security Alliance DAMAGES REQUIREMENTS (CSA). It is essential to ensure a proper separation of duties (Accidental) DESIGN during the development process, implementing DEVELOPMENT/IMP - Implementing Segregation of security controls in order to prevent security impacts. LEGAL LEMENTATION Duties. ISACA. Roles and PE-06. Implement a Without a separation of duties, people could carry TESTING AND

Privileges separation of duties in

out fraudulent activities in any phase by leveraging ACCEPTANCE - Secure Coding. Practical steps to the work team PHYSICAL ATTACK their privileges. The goal is to avoid the possibility of DEPLOYMENT AND defend your web apps. SANS. FAILURES / users having admin rights or inadequate profiles for INTEGRATION MALFUNCTIONS - Information technology — Security critical tasks. MAINTENANCE AND NEFARIOUS techniques — Information security DISPOSAL ACTIVITY / ABUSE management systems — DAMAGE / LOSS Requirements. ISO 27001

- Technical Considerations White Paper. FCC TAC.

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

- "Systems and software engineering — Software life cycle processes. ISO 12207"

- Fundamental Practices for Secure Software Development, SAFECODE

- BUILDING SECURITY IN MATURITY MODEL (BSIMM). BSIMM

- MITIGATING THE RISK OF SOFTWARE VULNERABILITIES BY ADOPTING A SECURE SOFTWARE DEVELOPMENT FRAMEWORK (SSDF). NIST

- The BSA Framework for Secure Software. BSA Software Alliance

- Security for industrial automation and control systems. Part 4-1: Secure product development lifecycle requirements. IEC 62443- 4-1

- Recommended Security Controls for Federal Information Systems and Organizations. NIST 800-53

PERSONNEL REQUIREMENTS UNINTENTIONAL - CSA IoT Security Controls The integrity of the development process must be DESIGN DAMAGES Framework. Cloud Security Alliance guaranteed. Implement security measures to access DEVELOPMENT/IMP (Accidental) (CSA) project resources so as to prevent any team member LEMENTATION Roles and PE-07. Protect the PHYSICAL ATTACK (insider, third-party) with privileges from disabling TESTING AND - The BSA Framework for Secure Privileges process against FAILURES / security controls, establishing or modifying policies ACCEPTANCE Software. BSA Software Alliance privilege abuse MALFUNCTIONS and guides, collecting sensitive data, etc. Perform DEPLOYMENT AND NEFARIOUS - BUILDING SECURITY IN audits periodically to ensure the integrity of INTEGRATION ACTIVITY / ABUSE MATURITY MODEL (BSIMM). information. MAINTENANCE AND DAMAGE / LOSS BSIMM DISPOSAL

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

- Fundamental Practices for Secure Software Development, SAFECODE

- MITIGATING THE RISK OF SOFTWARE VULNERABILITIES BY ADOPTING A SECURE SOFTWARE DEVELOPMENT FRAMEWORK (SSDF). NIST

- Security for industrial automation and control systems. Part 4-1: Secure product development lifecycle requirements. IEC 62443- 4-1

- Recommended Security Controls for Federal Information Systems and Organizations. NIST 800-53 - "Information technology — Security techniques — Information security management systems — Requirements. ISO 27001"

- Software Assurance Maturity Model (SAMM). OWASP SAMM

REQUIREMENTS PERSONNEL - CSA IoT Security Controls DESIGN Framework. Cloud Security Alliance Designate a person to perform, review and put forth OUTAGES (CSA) improvement actions for the business continuity DEVELOPMENT/IMP plan: preventing network crashes and service UNINTENTIONAL - The BSA Framework for Secure LEMENTATION Roles and PE-08. Allocate redundancies, safeguarding critical points that may DAMAGES Software. BSA Software Alliance Privileges resources for process (Accidental) TESTING AND slow down or compromise the development process ACCEPTANCE - "Systems and software engineering monitoring (SDLC), like the unavailability of third-party services, PHYSICAL ATTACK — Software life cycle processes. the uncontrolled access to sensitive locations where DEPLOYMENT AND ISO 12207" information is stored, the lack or expiry of software LEGAL INTEGRATION licences involved in the SDLC, etc. - MITIGATING THE RISK OF FAILURES / MAINTENANCE AND SOFTWARE VULNERABILITIES MALFUNCTIONS DISPOSAL BY ADOPTING A SECURE

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

NEFARIOUS SOFTWARE DEVELOPMENT ACTIVITY / ABUSE FRAMEWORK (SSDF). NIST DAMAGE / LOSS - Software Assurance Maturity Model (SAMM 1.5v). OWASP - Fundamental Practices for Secure Software Development, SAFECODE - BUILDING SECURITY IN MATURITY MODEL (BSIMM). BSIMM

- Recommended Security Controls for Federal Information Systems and Organizations. NIST 800-53 - Information security management. ISO 27001

- Security for industrial automation and control systems. Part 4-1: Secure product development lifecycle requirements. IEC 62443- 4-1

- CSA IoT Security Controls REQUIREMENTS Framework. Cloud Security Alliance DESIGN (CSA) OUTAGES Designate a resource responsible for fulfilling the DEVELOPMENT/IMP - The BSA Framework for Secure plan or procedure defined to take actions when risks PHYSICAL ATTACK LEMENTATION Software. BSA Software Alliance Roles and have to be mitigated and to contain them and PE-09. Designate a LEGAL TESTING AND - "Systems and software engineering Privileges prevent them from resulting in additional risks if

physical security officer

information regarding the SDLC or spaces where it is FAILURES / ACCEPTANCE — stored are compromised due to a fire, flood, electric MALFUNCTIONS DEPLOYMENT AND - Software life cycle processes. ISO show, etc. DAMAGE / LOSS INTEGRATION 12207"

MAINTENANCE AND - MITIGATING THE RISK OF DISPOSAL SOFTWARE VULNERABILITIES BY ADOPTING A SECURE

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

SOFTWARE DEVELOPMENT FRAMEWORK (SSDF). NIST

- Software Assurance Maturity Model (SAMM 1.5v). OWASP

- Fundamental Practices for Secure Software Development, SAFECODE

- BUILDING SECURITY IN MATURITY MODEL (BSIMM). BSIMM

- Recommended Security Controls for Federal Information Systems and Organizations. NIST 800-53

- Information security management. ISO 27001

- Security for industrial automation and control systems. Part 4-1: Secure product development lifecycle requirements. IEC 62443- 4-1

- "Payment Card Industry PERSONNEL - Software Security Framework. PCI UNINTENTIONAL REQUIREMENTS Security Standards Council" DAMAGES DESIGN (Accidental) - BUILDING SECURITY IN The profiles with security knowledge are essential in DEVELOPMENT/IMP MATURITY MODEL (BSIMM). the development process. Design a policy to reward LEMENTATION PE-10. Establish LEGAL BSIMM and stimulate this kind of profiles in order to reduce TESTING AND governance and PHYSICAL ATTACK Security Culture the risk of security knowledge being lost in the ACCEPTANCE - "Systems and software engineering controls for critical FAILURES / organisation, as well as internal threats: staff DEPLOYMENT AND - Software life cycle processes. ISO security know-how MALFUNCTIONS turnover, espionage, sabotage, etc. INTEGRATION 12207" NEFARIOUS MAINTENANCE AND ACTIVITY / ABUSE - "Information technology — Security DISPOSAL DAMAGE / LOSS techniques — Information security management systems — Requirements. ISO 27001"

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

- The BSA Framework for Secure Software. BSA Software Alliance

- Software Assurance Maturity Model (SAMM). OWASP SAMM

- Security for industrial automation and control systems. Part 4-1: Secure product development lifecycle requirements. IEC 62443- 4-1

- BUILDING SECURITY IN MATURITY MODEL (BSIMM). BSIMM

- "Systems and software engineering — Engage internal or external security support to PERSONNEL REQUIREMENTS - Software life cycle processes. ISO complement, support, or cover security aspects and UNINTENTIONAL DESIGN 12207" to contribute during specific activities, such as: DAMAGES DEVELOPMENT/IMP - Use of external penetration testers during the (Accidental) - SECURE CODING BEST LEMENTATION PE-11. Consult with testing phase to provide with different perspectives, LEGAL PRACTICES HANDBOOK. Security Culture TESTING AND security experts to adding robustness to the process. PHYSICAL ATTACK VERACODE ACCEPTANCE improve the process - Use of specific expert in security tools to control FAILURES / DEPLOYMENT AND - "Information technology — Security access to the process resources, increasing the MALFUNCTIONS INTEGRATION techniques — Information security confidentiality and integrity throughout all phases NEFARIOUS MAINTENANCE AND management systems — - Use of a coach to bring security into the SDLC ACTIVITY / ABUSE DISPOSAL Requirements. ISO 27001" phases, etc. DAMAGE / LOSS - Recommended Security Controls for Federal Information Systems and Organizations. NIST 800-53

- Software Assurance Maturity Model (SAMM). OWASP SAMM

Designate a role to centralise all issues related to PERSONNEL REQUIREMENTS - Software Security Takes a PE-12. Designate a software development security. This figure should UNINTENTIONAL DESIGN Security Culture Champion. SAFECODE Security Champion not be responsible for the implementation of security DAMAGES DEVELOPMENT/IMP figure functions, but for coordination, follow-up, planning, (Accidental) LEMENTATION - The BSA Framework for Secure and monitoring efforts and activities related to LEGAL TESTING AND Software. BSA Software Alliance security. This position should be understood as a PHYSICAL ATTACK ACCEPTANCE

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

bridge, a security catalyst among organisation FAILURES / DEPLOYMENT AND - NISTIR 8200 - Interagency Report statements (developers, team leaders and decision- MALFUNCTIONS INTEGRATION on the Status of International makers). NEFARIOUS MAINTENANCE AND Cybersecurity Standardization for ACTIVITY / ABUSE DISPOSAL the Internet of Things (IoT). NIST DAMAGE / LOSS - "Information technology — Security techniques — Information security management systems — Requirements. ISO 27001"

- SECURE CODING BEST PRACTICES HANDBOOK. VERACODE

- BUILDING SECURITY IN MATURITY MODEL (BSIMM). BSIMM

- MITIGATING THE RISK OF SOFTWARE VULNERABILITIES BY ADOPTING A SECURE SOFTWARE DEVELOPMENT FRAMEWORK (SSDF). NIST

- Recommended Security Controls for Federal Information Systems and Organizations. NIST 800-53

- Security Champions. OWASP

- GSMA IoT Security Assessment Checklist - Reference CLP11_7

Designate a resource (internal or through a third- OUTAGES REQUIREMENTS - The BSA Framework for Secure party service) to monitor, operate and respond to Software. BSA Software Alliance alarms generated by events resulting from the loss UNINTENTIONAL PE-13. Monitor and DESIGN or poor performance of the infrastructures that DAMAGES - CSA IoT Security Controls

Security Culture respond to the

support the secure development process (sSDLC), (Accidental) DEVELOPMENT/IMP Framework. Cloud Security Alliance

supporting security

which are essential for correct functioning. This LEMENTATION (CSA) incidents LEGAL would be the case of communications slowing down TESTING AND - Proactive Controls for developers or being lost, preventing the exchange of FAILURES / ACCEPTANCE v3.0. OWASP documentation between team members or with third MALFUNCTIONS parties, as well as the loss or unavailability of data

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

repositories, be they owned or through a cloud DAMAGE / LOSS DEPLOYMENT AND - "Systems and software engineering service, etc. INTEGRATION —Software life cycle processes. ISO 12207" MAINTENANCE AND DISPOSAL - Fundamental Practices for Secure Software Development, SAFECODE

- The BSA Framework for Secure Software. BSA Software Alliance

- NISTIR 8200 - Interagency Report on the Status of International Cybersecurity Standardization for the Internet of Things (IoT). NIST

- NIST SP 800 53r5: Security and Privacy Controls for Federal Information Systems and Organizations. NIST - ISO-IEC 27001. ISO

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

4.4 PROCESSES

SSDLC phases Security domain Title Description Threats Reference title involved

- Security for industrial automation and control systems. Part 4-1: Secure product development lifecycle requirements. IEC 62443- 4-1

- Software Assurance Maturity Model (SAMM 1.5v). OWASP

- MITIGATING THE RISK OF SOFTWARE VULNERABILITIES BY ADOPTING A SECURE SOFTWARE DEVELOPMENT FRAMEWORK (SSDF). NIST During a SDLC process, components or services are outsourced to a third-party (external supplier). - BUILDING SECURITY IN A supply chain management plan should be PERSONNEL REQUIREMENTS MATURITY MODEL (BSIMM). implemented and integrated into this process to UNINTENTIONAL DESIGN BSIMM ensure the integrity of the SDLC. DAMAGES DEVELOPMENT/IMP - The BSA Framework for Secure This plan should include information related to OUTAGES LEMENTATION Software. BSA Software Alliance Third-Party PR-01. Implement a supply security frameworks to be used, risk management, LEGAL TESTING AND Management chain management plan third-party acquisition management, purchasing FAILURES / ACCEPTANCE - Proactive Controls for developers contract definition, etc., as well as controls that MALFUNCTIONS DEPLOYMENT AND v3.0. OWASP prevent third-party tampering or compromise, e.g. NEFARIOUS INTEGRATION - "Systems and software engineering avoiding reverse engineering to better understand ACTIVITY / ABUSE MAINTENANCE AND —Software life cycle processes. how a software works and to leverage this DAMAGE / LOSS DISPOSAL knowledge to carry-out malicious activities (anti- ISO 12207" reverse engineering). - SECURE CODING BEST PRACTICES HANDBOOK. VERACODE

- Fundamental Practices for Secure Software Development, SAFECODE

- BUILDING SECURITY IN MATURITY MODEL (BSIMM). BSIMM

- CSA IoT Security Controls Framework. Cloud Security Alliance (CSA)

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

- Application Security Verification Standard 4.0 (ASVS). OWASP

- NIST SP 800 53r5: Security and Privacy Controls for Federal Information Systems and Organizations. NIST

- ISO-IEC 27001. ISO

- GSMA IoT Security Assessment Checklist - Reference CLP11_7

- Software Assurance Maturity Model (SAMM 1.5v). OWASP

- BUILDING SECURITY IN MATURITY MODEL (BSIMM). BSIMM

- OWASP Dependency-Check. OWASP

- The BSA Framework for Secure Software. BSA Software Alliance Ensure a proper management of third parties and dependencies of the software development using - Proactive Controls for developers PERSONNEL REQUIREMENTS risk management and integrating security v3.0. OWASP UNINTENTIONAL DESIGN requirements in contracts, ensuring the visibility DAMAGES DEVELOPMENT/IMP - Security Assurance in the SDLC for and traceability of components, documenting all OUTAGES LEMENTATION components and subcomponents acquired, the Internet of Things - ISACA. Third-Party PR-02. Assess the software LEGAL TESTING AND managing incidents, scanning dependencies, etc. ISACA Management dependency process FAILURES / ACCEPTANCE CVSS must be consulted when choosing a third- MALFUNCTIONS DEPLOYMENT AND - SECURE CODING BEST party software/library and dependencies must be NEFARIOUS INTEGRATION PRACTICES HANDBOOK. checked periodically or every time they are ACTIVITY / ABUSE MAINTENANCE AND VERACODE updated. An open-source update plan for IoT must DAMAGE / LOSS DISPOSAL be considered and followed, monitoring and - Fundamental Practices for Secure managing third-party vulnerabilities. Software Development, SAFECODE

- CSA IoT Security Controls Framework. Cloud Security Alliance (CSA)

- Application Security Verification Standard 4.0 (ASVS). OWASP

- Security for industrial automation and control systems. Part 4-1: Secure product development

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

lifecycle requirements. IEC 62443- 4-1

- NIST SP 800 53r5: Security and Privacy Controls for Federal Information Systems and Organizations. NIST

- ISO-IEC 27001. ISO

- CSA IoT Security Controls Framework. Cloud Security Alliance (CSA)

- Proactive Controls for developers v3.0. OWASP

- "Systems and software engineering —Software life cycle processes. ISO 12207"

- SECURE CODING BEST PRACTICES HANDBOOK. VERACODE PERSONNEL - Fundamental Practices for Secure Define a process to secure third-party code by UNINTENTIONAL Software Development, performing controls in order to detect vulnerable DAMAGES SAFECODE components, such as penetration tests, fuzzing OUTAGES Third-Party PR-03. Test third-party tests, validation tests, etc. LEGAL TESTING AND - The BSA Framework for Secure Management processes The objective is to verify that the technical, FAILURES / ACCEPTANCE Software. BSA Software Alliance functional, and business requirements are met. MALFUNCTIONS It is recommended to execute this process in every NEFARIOUS - BUILDING SECURITY IN iteration (sprint). ACTIVITY / ABUSE MATURITY MODEL (BSIMM). DAMAGE / LOSS BSIMM

- MITIGATING THE RISK OF SOFTWARE VULNERABILITIES BY ADOPTING A SECURE SOFTWARE DEVELOPMENT FRAMEWORK (SSDF). NIST

- Application Security Verification Standard 4.0 (ASVS). OWASP

- NIST SP 800 53r5: Security and Privacy Controls for Federal Information Systems and Organizations. NIST

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

- The BSA Framework for Secure Software. BSA Software Alliance

- Security for industrial automation and control systems. Part 4-1: Secure product development lifecycle requirements. IEC 62443- 4-1

- Software Assurance Maturity Model (SAMM 1.5v). OWASP

- ISO-IEC 27001. ISO

- GSMA IoT Security Assessment Checklist - Reference CLP11_7

- "Systems and software engineering —Software life cycle processes. ISO 12207"

- Security for industrial automation and control systems. Part 4-1: Secure product development lifecycle requirements. IEC 62443- 4-1

- MITIGATING THE RISK OF PERSONNEL SOFTWARE VULNERABILITIES Verify that the software provided by third parties UNINTENTIONAL BY ADOPTING A SECURE meets the security requirements, including the DAMAGES SOFTWARE DEVELOPMENT requirements specified in contracts. Define OUTAGES DEVELOPMENT/IMP FRAMEWORK (SSDF). NIST Third-Party PR-04. Verify third-party requirements for commercial software and verify LEGAL LEMENTATION Management software and services - Proactive Controls for developers the evidence provided by the supplier (audits, FAILURES / TESTING AND testing, software certifications, etc.). MALFUNCTIONS ACCEPTANCE v3.0. OWASP It is advisable to check that the requirements have NEFARIOUS - SECURE CODING BEST been met at least every time a delivery occurs. ACTIVITY / ABUSE PRACTICES HANDBOOK. DAMAGE / LOSS VERACODE

- Fundamental Practices for Secure Software Development, SAFECODE

- Software Assurance Maturity Model (SAMM 1.5v). OWASP

- CSA IoT Security Controls Framework. Cloud Security Alliance (CSA)

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

- Application Security Verification Standard 4.0 (ASVS). OWASP

- The BSA Framework for Secure Software. BSA Software Alliance

- Security for industrial automation and control systems. Part 4-1: Secure product development lifecycle requirements. IEC 62443- 4-1

- ISO-IEC 27001. ISO

- NIST SP 800 53r5: Security and Privacy Controls for Federal Information Systems and Organizations. NIST

- Security for industrial automation and control systems. Part 4-1: Secure product development lifecycle requirements. IEC 62443- 4-1

- Software Assurance Maturity Model (SAMM 1.5v). OWASP

- MITIGATING THE RISK OF SOFTWARE VULNERABILITIES Establish a procedure for the organisation to know BY ADOPTING A SECURE the steps to be taken in the event of requiring OUTAGES SOFTWARE DEVELOPMENT support from external providers to face events or UNINTENTIONAL FRAMEWORK (SSDF). NIST DEPLOYMENT AND PR-05. Disseminate a incidents concerning cloud services, testing DAMAGES Third-Party INTEGRATION - BUILDING SECURITY IN communication procedure services, etc., indicating at least the person of (accidental) Management MAINTENANCE AND MATURITY MODEL (BSIMM). to request external support contact in charge of the service, the request model FAILURES / DISPOSAL BSIMM and communication channel, incident follow-up MALFUNCTIONS and management, the remediation, documentation DAMAGE / LOSS - The BSA Framework for Secure updates, version, etc. Software. BSA Software Alliance

- Proactive Controls for developers v3.0. OWASP

- "Systems and software engineering —Software life cycle processes. ISO 12207"

- SECURE CODING BEST PRACTICES HANDBOOK. VERACODE

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

- Fundamental Practices for Secure Software Development, SAFECODE

- BUILDING SECURITY IN MATURITY MODEL (BSIMM). BSIMM

- CSA IoT Security Controls Framework. Cloud Security Alliance (CSA)

- Application Security Verification Standard 4.0 (ASVS) . OWASP

- NIST SP 800 53r5: Security and Privacy Controls for Federal Information Systems and Organizations. NIST

- ISO-IEC 27001. ISO

- Security for industrial automation and control systems. Part 4-1: Secure product development lifecycle requirements. IEC 62443- 4-1

- Software Assurance Maturity Model (SAMM 1.5v). OWASP REQUIREMENTS - MITIGATING THE RISK OF DESIGN SOFTWARE VULNERABILITIES Require, audit, and specify confidentiality clauses PERSONNEL DEVELOPMENT/IMP for all internal and external personnel with access OUTAGES BY ADOPTING A SECURE LEMENTATION to the facilities with a view to preventing leakages PHYSICAL ATTACK SOFTWARE DEVELOPMENT Third-Party PR-06. Protect data against TESTING AND of information on topics such as software design or LEGAL FRAMEWORK (SSDF). NIST Management leakages ACCEPTANCE architecture, which may represent sabotage or NEFARIOUS DEPLOYMENT AND - BUILDING SECURITY IN espionage attempts during any of the phases of ACTIVITY / ABUSE INTEGRATION MATURITY MODEL (BSIMM). the product development (SDLC). DAMAGE / LOSS MAINTENANCE AND BSIMM DISPOSAL - The BSA Framework for Secure Software. BSA Software Alliance

- Proactive Controls for developers v3.0. OWASP

- "Systems and software engineering —Software life cycle processes. ISO 12207"

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

- SECURE CODING BEST PRACTICES HANDBOOK. VERACODE

- Fundamental Practices for Secure Software Development, SAFECODE

- BUILDING SECURITY IN MATURITY MODEL (BSIMM). BSIMM

- CSA IoT Security Controls Framework. Cloud Security Alliance (CSA)

- Application Security Verification Standard 4.0 (ASVS) . OWASP

- NIST SP 800 53r5: Security and Privacy Controls for Federal Information Systems and Organizations. NIST

- ISO-IEC 27001. ISO

- Software Assurance Maturity Model (SAMM 1.5v). OWASP

- MITIGATING THE RISK OF SOFTWARE VULNERABILITIES BY ADOPTING A SECURE SOFTWARE DEVELOPMENT By means of contractual clauses, ensure that both FRAMEWORK (SSDF). NIST internal and external service providers implement OUTAGES security controls to measure the quality of the - BUILDING SECURITY IN LEGAL PR-07. Contractually require service (e.g. service incident response time, MATURITY MODEL (BSIMM). FAILURES / Third-Party controlling and monitoring unavailability terms, etc.) and detect potential BSIMM MALFUNCTIONS REQUIREMENTS Management the external services flaws, stipulating a reporting period (e.g. on a NEFARIOUS - The BSA Framework for Secure through KPI's weekly basis) for the KPIs to assess the service, ACTIVITY / ABUSE Software. BSA Software Alliance along with measures to be taken to prevent DAMAGE / LOSS impacts on the SDLC phases, such as, for - Proactive Controls for developers instance, the maintenance phase. v3.0. OWASP

- "Systems and software engineering —Software life cycle processes. ISO 12207"

- NIST SP 800 53r5: Security and Privacy Controls for Federal

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

Information Systems and Organizations. NIST

- ISO-IEC 27001. ISO

- The BSA Framework for Secure Software. BSA Software Alliance

- Security for industrial automation and control systems. Part 4-1: Secure product development lifecycle requirements. IEC 62443- Provide guidance for the definition and allocation 4-1 of roles, responsibilities and activities to be - CSA IoT Security Controls implemented by the organisations in the event of Framework. Cloud Security Alliance security incidents. (CSA) Security incidents pose a higher impact as the SDLC process reaches the last stages, so it is - Proactive Controls for developers crucial to manage it following an established v3.0. OWASP PERSONNEL resolution process. This process should contain at UNINTENTIONAL - "Systems and software engineering least: - Incident detection and registration. DAMAGES —Software life cycle processes. - Classification and initial support. OUTAGES ISO 12207" PHYSICAL DEPLOYMENT AND - Research and diagnosis. Operations PR-08. Define an Incident ATTACKS INTEGRATION - Fundamental Practices for Secure - Solution and service restoration. Management Management plan LEGAL MAINTENANCE AND Software Development, - Incident closure. FAILURES / DISPOSAL SAFECODE - Monitoring, follow-up and communication of the MALFUNCTIONS incident. - The BSA Framework for Secure NEFARIOUS Software. BSA Software Alliance Maintain, to the greatest extent feasible, a full ACTIVITY / ABUSE inventory of third party components and DAMAGE / LOSS - NISTIR 8200 - Interagency Report dependencies, and track vulnerabilities, patches, on the Status of International and updates to those components to preserve Cybersecurity Standardization for security. the Internet of Things (IoT). NIST

- MITIGATING THE RISK OF An Incident Management Plan should be defined SOFTWARE VULNERABILITIES and periodically updated. BY ADOPTING A SECURE SOFTWARE DEVELOPMENT FRAMEWORK (SSDF). NIST

- NIST SP 800 53r5: Security and Privacy Controls for Federal Information Systems and Organizations. NIST

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

- ISO-IEC 27001. ISO

- GSMA IoT Security Assessment Checklist - Reference CLP11_5

- The BSA Framework for Secure Software. BSA Software Alliance

- "Payment Card Industry

- Software Security Framework. PCI Security Standards Council" A Change Management Plan should be defined to manage any changes that may be take place - Proactive Controls for developers during the SDLC process. This entails ensuring v3.0. OWASP control over the budget, schedule, scope, - "Systems and software engineering communication, and resources. The main focus is —Software life cycle processes. to minimise the impact a change throughout the process could have on the different assets: ISO 12207" business, team, users, and other important PERSONNEL - CSA IoT Security Controls stakeholders. UNINTENTIONAL Framework. Cloud Security Alliance Change management is a highly important activity DAMAGES (CSA) both in the development and integration phases OUTAGES DEPLOYMENT AND Operations PR-09. Define a Change (changes may affect the requirements) as well as LEGAL INTEGRATION - Security for industrial automation Management Management plan in the maintenance and disposal, during updates, FAILURES / MAINTENANCE AND and control systems. Part 4-1: patches or functionalities changes. MALFUNCTIONS DISPOSAL Secure product development The plan should detail a procedure containing at NEFARIOUS lifecycle requirements. IEC 62443least: ACTIVITY / ABUSE 4-1 - Identification and formal request. DAMAGE / LOSS - ISO-IEC 27001. ISO - Impact analysis and assessment. - NISTIR 8200 - Interagency Report - Validation. on the Status of International - Planning and testing. Cybersecurity Standardization for - Implementation. the Internet of Things (IoT). NIST - Monitoring, follow-up and communication of the change. - NIST SP 800 53r5: Security and Privacy Controls for Federal Information Systems and Organizations. NIST

- GSMA IoT Security Assessment Checklist - Reference CLP11_5

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

- MITIGATING THE RISK OF

SOFTWARE VULNERABILITIES

BY ADOPTING A SECURE SOFTWARE DEVELOPMENT

FRAMEWORK (SSDF). NIST

- The BSA Framework for Secure

Software. BSA Software Alliance

- CSA IoT Security Controls Framework. Cloud Security Alliance Develop a process for vulnerability and update (CSA) management as well as for vulnerability disclosure

from external and internal parties to reduce the risk - Proactive Controls for developers

of system failures, especially in operation. This v3.0. OWASP process must encompass identification and patching processes and the communication - Fundamental Practices for Secure PERSONNEL Software Development, process with the relevant stakeholders when a DEPLOYMENT AND PR-10. Implement LEGAL SAFECODE Operations vulnerability is discovered. This guide should INTEGRATION Vulnerability and Patch FAILURES / Management document the process and controls to be carried MAINTENANCE AND Management MALFUNCTIONS - BUILDING SECURITY IN out by the project team, such as: DISPOSAL DAMAGE / LOSS MATURITY MODEL (BSIMM). - Vulnerability discovery/disclosure BSIMM - Identification of the affected asset - Development of the solution or patch - Security for industrial automation

- Testing, solution compliance and control systems. Part 4-1:

- Patch implementation, update Secure product development

- Update follow-up lifecycle requirements. IEC 62443-

4-1

- ISO-IEC 27001. ISO

- NIST SP 800 53r5: Security and

Privacy Controls for Federal

Information Systems and

Organizations. NIST

- GSMA IoT Security Assessment Checklist - Reference CLP12_5

Configuration management focuses on maintaining PERSONNEL - The BSA Framework for Secure the integrity of the system, ensuring that LEGAL Software. BSA Software Alliance uncontrolled changes are implemented during the UNINTENTIONAL DEPLOYMENT AND deployment and maintenance phases of the SDLC Operations PR-11. Implement DAMAGES INTEGRATION - MITIGATING THE RISK OF process. It must be configured in a restrictive way Management Configuration Management (Accidental) MAINTENANCE AND SOFTWARE VULNERABILITIES to guarantee maximum resistance against FAILURES / DISPOSAL BY ADOPTING A SECURE malicious or unintentional attacks (changes to a SOFTWARE DEVELOPMENT MALFUNCTIONS file or code element, adaptation of security settings FRAMEWORK (SSDF). NIST DAMAGE / LOSS on the operating environment, etc.).

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

- Application Security Verification Standard 4.0 (ASVS) . OWASP

- Proactive Controls for developers v3.0. OWASP

- Security Assurance in the SDLC for the Internet of Things - ISACA. ISACA

- "Systems and software engineering —Software life cycle processes. ISO 12207"

- SECURE CODING BEST PRACTICES HANDBOOK. VERACODE

- Fundamental Practices for Secure Software Development, SAFECODE

- CSA IoT Security Controls Framework. Cloud Security Alliance (CSA)

- Application Security Verification Standard 4.0 (ASVS). OWASP

- Security for industrial automation and control systems. Part 4-1: Secure product development lifecycle requirements. IEC 62443- 4-1

- NIST SP 800 53r5: Security and Privacy Controls for Federal Information Systems and Organizations. NIST

- ISO-IEC 27001. ISO

- GSMA IoT Security Assessment Checklist - Reference CLP11_5

The access to resources and processes should be PEPERSONNEL DEVELOPMENT/IMP - The BSA Framework for Secure protected to prevent users without authorisation UNINTENTIONAL LEMENTATION PR-12. Establish a Control Software. BSA Software Alliance SDLC from accessing restricted resources (e.g. data DAMAGES TESTING AND Access and Authorisation repository, password storage, test reports, etc.) at Methodology OUTAGES ACCEPTANCE - Fundamental Practices for Secure policy any stage of the SDLC process. Software Development, DEPLOYMENT AND By establishing user access privileges, it is PHYSICAL SAFECODE INTEGRATION possible to ensure the confidentiality, integrity and ATTACKS

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

availability of data and process: LEGAL MAINTENANCE AND - Proactive Controls for developers - Only authorised persons (based on their FAILURES / DISPOSAL v3.0. OWASP privileges) will be able to access the resources MALFUNCTIONS (phases, information, systems, equipment, NEFARIOUS - Application Security Verification programs, applications, databases, networks, etc.). ACTIVITY / ABUSE Standard 4.0 (ASVS). OWASP - The control access will make it possible to DAMAGE / LOSS - CSA IoT Security Controls identify and audit the accesses that have taken Framework. Cloud Security Alliance place, establishing internal security controls. (CSA)

- The BSA Framework for Secure Software. BSA Software Alliance

- SECURE CODING BEST PRACTICES HANDBOOK. VERACODE

- MITIGATING THE RISK OF SOFTWARE VULNERABILITIES BY ADOPTING A SECURE SOFTWARE DEVELOPMENT FRAMEWORK (SSDF). NIST

- Security for industrial automation and control systems. Part 4-1: Secure product development lifecycle requirements. IEC 62443- 4-1

- NISTIR 8200 - Interagency Report on the Status of International Cybersecurity Standardization for the Internet of Things (IoT). NIST

- NIST SP 800 53r5: Security and Privacy Controls for Federal Information Systems and Organizations. NIST

- ISO-IEC 27001. ISO

- GSMA IoT Security Assessment Checklist - Reference CLP11_5

DEVELOPMENT/IMP Processes supported by tested tools should be PERSONNEL LEMENTATION UNINTENTIONAL - MITIGATING THE RISK OF automated in order to reduce costs and human TESTING AND DAMAGES SOFTWARE VULNERABILITIES SDLC PR-13. Automate the SDLC efforts and errors. The main objective is to improve ACCEPTANCE the monitoring and measurement of development LEGAL BY ADOPTING A SECURE Methodology process DEPLOYMENT AND progress, as well as the implementation of security FAILURES / SOFTWARE DEVELOPMENT INTEGRATION MALFUNCTIONS FRAMEWORK (SSDF). NIST measures for the process. The result of automated MAINTENANCE AND NEFARIOUS testing must be analysed, since automated tools DISPOSAL

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

are based on patterns that can suffer ACTIVITY / ABUSE - BUILDING SECURITY IN modifications, which may not be detected and DAMAGE / LOSS MATURITY MODEL (BSIMM). produce false positives. In cases where this is not BSIMM possible, manual tools should be used. It is recommended to execute this process in every - ISO-IEC 27001. ISO iteration (sprint). - The BSA Framework for Secure Software. BSA Software Alliance

- Security for industrial automation and control systems. Part 4-1: Secure product development lifecycle requirements. IEC 62443- 4-1

- The BSA Framework for Secure Software. BSA Software Alliance

- MITIGATING THE RISK OF SOFTWARE VULNERABILITIES BY ADOPTING A SECURE SOFTWARE DEVELOPMENT FRAMEWORK (SSDF). NIST

- CSA IoT Security Controls Implement security metrics, which should be Framework. Cloud Security Alliance defined and tracked in order to verify that the (CSA) specified security requirements have been fulfilled - SECURE CODING BEST during the Software Development process. REQUIREMENTS PERSONNEL PRACTICES HANDBOOK. Checking the security metrics should be a DESIGN UNINTENTIONAL VERACODE necessary requirement to: DEVELOPMENT/IMP DAMAGES - Evaluate the security maturity and identify actions LEMENTATION - Software Assurance Maturity Model LEGAL SDLC PR-14. Define security to improve the process (SMM). TESTING AND (SAMM 1.5v). OWASP FAILURES / Methodology metrics ACCEPTANCE MALFUNCTIONS - Reassure quality for all SDLC phases. DEPLOYMENT AND - BUILDING SECURITY IN NEFARIOUS - Assess the status of an ongoing process. INTEGRATION MATURITY MODEL (BSIMM). ACTIVITY / ABUSE - Track potential risks. MAINTENANCE AND BSIMM - Discover process issues before they become DAMAGE / LOSS DISPOSAL - The BSA Framework for Secure critical. Software. BSA Software Alliance - Evaluate the ability of the project team to control the quality of software products. - Security for industrial automation and control systems. Part 4-1: Secure product development lifecycle requirements. IEC 62443- 4-1

- The BSA Framework for Secure Software. BSA Software Alliance

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

- "Payment Card Industry

- Software Security Framework. PCI

Security Standards Council"

- "Software Assurance Maturity

Model (SAMM)

Adopt a software assurance maturity model for - BUILDING SECURITY IN REQUIREMENTS software development to identify security best MATURITY MODEL (BSIMM). DESIGN practices during the process (e.g. OWASP SAMM PERSONNEL OWASP SAMM DEVELOPMENT/IMP and BSIMM). The implementation of security is UNINTENTIONAL LEMENTATION - BSIMM" considered mature if the mechanisms used DAMAGES SDLC PR-15. Adopt a maturity TESTING AND effectively achieve the security requirements. The (Accidental) - Security for industrial automation Methodology model ACCEPTANCE analysis takes account of specific threats to the FAILURES / and control systems. Part 4-1: DEPLOYMENT AND regulatory and compliance requirements of an MALFUNCTIONS Secure product development INTEGRATION organisation's industry, the unique risks present in DAMAGE / LOSS lifecycle requirements. IEC 62443- MAINTENANCE AND an environment, and the organisation's threat 4-1 DISPOSAL profile.

- CSA IoT Security Controls

Framework. Cloud Security Alliance

(CSA)

- BSIMM.

- The BSA Framework for Secure

Software. BSA Software Alliance.

- SECURE CODING BEST

PRACTICES HANDBOOK.

VERACODE

- BUILDING SECURITY IN

MATURITY MODEL (BSIMM). Define security guides establishing the REQUIREMENTS BSIMM performance of security tests during the different DESIGN PERSONNEL phases of development, defining best practices DEVELOPMENT/IMP - Application Security Verification UNINTENTIONAL such as the generation of use cases, the LEMENTATION Standard 4.0 (ASVS). OWASP PR-16. Define and DAMAGES SDLC performance of penetration tests during TESTING AND document the SDLC (Accidental) Methodology development, the use of tools, the performance of ACCEPTANCE - Security for industrial automation process FAILURES / and control systems. Part 4-1: security tests at the end of the process, etc. DEPLOYMENT AND MALFUNCTIONS Secure product development It is recommended to execute this process in every INTEGRATION DAMAGE / LOSS iteration (sprint) or when a modification is MAINTENANCE AND lifecycle requirements. IEC 62443-

implemented. DISPOSAL 4-1

- Proactive Controls for developers

v3.0. OWASP

- The BSA Framework for Secure

Software. BSA Software Alliance

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

- Security for industrial automation and control systems. Part 4-1: Secure product development lifecycle requirements. IEC 62443- 4-1

- The BSA Framework for Secure Software. BSA Software Alliance

- CSA IoT Security Controls Framework. Cloud Security Alliance A plan for the withdrawal of the solution at the end (CSA) of the life-cycle must be considered. The plan must PERSONNEL include measures to formally retire stored data - Proactive Controls for developers UNINTENTIONAL Secure PR-17. Define a disposal according to the needs (organisational, data MAINTENANCE AND v3.0. OWASP DAMAGES Deployment strategy privacy, regulatory compliance) including third- DISPOSAL (Accidental) / party components and the communication to the - "Systems and software engineering LEGAL —Software life cycle processes. stakeholders. To ensure the disposal process, an audit log must be maintained. ISO 12207"

- NIST SP 800 53r5: Security and Privacy Controls for Federal Information Systems and Organizations. NIST

- ISO-IEC 27001. ISO

- GSMA IoT Security Assessment Checklist - Reference CLP12_5 and CLP13_8

Establish a procedure to inform of new published vulnerabilities (e.g. establishing mechanisms to - CSA IoT Security Controls receive feedback from security research PERSONNEL Framework. Cloud Security Alliance community) that may affect the software OUTAGES REQUIREMENTS (CSA) development life cycle (including those that affect UNINTENTIONAL DESIGN - "Systems and software engineering third party components), so that they can be taken DAMAGES DEVELOPMENT/IMP PR-18. Establish process into account in all phases. This information (Accidental) LEMENTATION —Software life cycle processes. Secure for SDLC vulnerabilities measure can help the organisation not to incur into PHYSICAL ATTACK TESTING AND ISO 12207" Deployment follow-up, monitoring and known errors, and to take them into account as LEGAL ACCEPTANCE - Recommended Security Controls updates security requirements in the requirements phase of FAILURES / DEPLOYMENT AND for Federal Information Systems the SDLC for future developments. This includes MALFUNCTIONS INTEGRATION and Organizations. NIST 800-53 not only for software development projects but also NEFARIOUS MAINTENANCE AND as requirements to be stipulated with third parties ACTIVITY / ABUSE DISPOSAL - BUILDING SECURITY IN for services or infrastructure, such as external data DAMAGE / LOSS MATURITY MODEL (BSIMM). repository services for backups or access control BSIMM systems for server rooms.

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

- Security for industrial automation

and control systems. Part 4-1:

Secure product development lifecycle requirements. IEC 62443-

4-1.

- BUILDING SECURITY IN

MATURITY MODEL (BSIMM).

BSIMM.

- MITIGATING THE RISK OF

SOFTWARE VULNERABILITIES

BY ADOPTING A SECURE

SOFTWARE DEVELOPMENT Define testing strategy that eliminates trivial bugs PERSONNEL FRAMEWORK (SSDF). NIST. DEVELOPMENT/IMP by utilizing automated tools for both static and UNINTENTIONAL LEMENTATION - Fundamental Practices for Secure dynamic analysis. Use infrastructure-as-code or DAMAGES TESTING AND LEGAL Software Development, Secure PR-19. Implement a testing digital twins to ensure accuracy of testing ACCEPTANCE FAILURES / SAFECODE. Deployment strategy processes for IoT in critical infrastructure. DEPLOYMENT AND MALFUNCTIONS This strategy should contain considerations such INTEGRATION - Security Assurance in the SDLC for NEFARIOUS as test scope definition, criteria to be used, quality MAINTENANCE AND the Internet of Things - ISACA. ACTIVITY / ABUSE DISPOSAL ISACA. control points, procedures to solve errors, etc. DAMAGE / LOSS

- NIST SP 800 53r5: Security and

Privacy Controls for Federal

Information Systems and

Organizations. NIST.

- BUILDING SECURITY IN MATURITY MODEL (BSIMM).

BSIMM.

- Application Security Verification

Standard 4.0 (ASVS). OWASP.

- The BSA Framework for Secure Software. BSA Software Alliance.

- The BSA Framework for Secure Define effective and secure deployment strategy, weighing the options in terms of the impact of PERSONNEL Software. BSA Software Alliance.

change on the targeted systems, and the end- LEGAL - MITIGATING THE RISK OF users. UNINTENTIONAL DEPLOYMENT AND SOFTWARE VULNERABILITIES Secure PR-20. Define a secure DAMAGES INTEGRATION BY ADOPTING A SECURE Deployment deployment strategy It must be considered that only qualified personnel (Accidental) MAINTENANCE AND SOFTWARE DEVELOPMENT must have access to deployment environment, FAILURES / DISPOSAL audit systems for all deployments establishing FRAMEWORK (SSDF). NIST. MALFUNCTIONS versions control, acceptance threshold, person DAMAGE / LOSS - Application Security Verification who conducted it, etc. Standard 4.0 (ASVS). OWASP.

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

- Proactive Controls for developers v3.0. OWASP.

- Security Assurance in the SDLC for the Internet of Things - ISACA. ISACA.

- "Systems and software engineering —

- Software life cycle processes. ISO 12207. "

- SECURE CODING BEST PRACTICES HANDBOOK. VERACODE.

- Fundamental Practices for Secure Software Development, SAFECODE.

- CSA IoT Security Controls Framework. Cloud Security Alliance (CSA).

- Application Security Verification Standard 4.0 (ASVS). OWASP.

- Security for industrial automation and control systems. Part 4-1: Secure product development lifecycle requirements. IEC 62443- 4-1.

- NIST SP 800 53r5: Security and Privacy Controls for Federal Information Systems and Organizations. NIST.

- ISO-IEC 27001. ISO.

Adopt a security framework encompassing the - Security for industrial automation necessary requirements in order to define and PERSONNEL and control systems. Part 4-1: provide guides and policies to be implemented UNINTENTIONAL Secure product development throughout the Software Development Life Cycle DAMAGES lifecycle requirements. IEC 62443- PR-21. Provide a secure process. Known frameworks minimise risks and (Accidental) REQUIREMENTS Security Design 4-1 framework threats that could affect the process. Define a LEGAL DESIGN secure framework to ensure in-depth defence and FAILURES / - "Payment Card Industry observe security by design considering the entire MALFUNCTIONS life cycle of the solution and comprising the design, DAMAGE / LOSS - Software Security Framework. PCI maintenance, and disposal phases. Security Standards Council"

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

- ISO-IEC 27001. ISO

- "Systems and software engineering —Software life cycle processes. ISO 12207"

- SECURE CODING BEST PRACTICES HANDBOOK. VERACODE

- BUILDING SECURITY IN MATURITY MODEL (BSIMM). BSIMM

- The BSA Framework for Secure Software. BSA Software Alliance

- CSA IoT Security Controls Framework. Cloud Security Alliance (CSA)

- Software Assurance Maturity Model (SAMM). OWASP SAMM

- Security-First Design for IoT Devices - IoTCentral. IoTCentral

- Application Security Verification Standard 4.0 (ASVS). OWASP

- The BSA Framework for Secure Software. BSA Software Alliance

- Security for industrial automation and control systems. Part 4-1: Secure product development REQUIREMENTS Ensure that user and software privileges are lifecycle requirements. IEC 62443- DESIGN strictly limited to features required to carry out the PERSONNEL 4-1 DEVELOPMENT/IMP operations. Limiting permissions and rights in the UNINTENTIONAL LEMENTATION - SECURE CODING BEST tasks to be performed is an important activity DAMAGES PR-22. Apply least privilege TESTING AND PRACTICES HANDBOOK. Security Design during the SDLC process, gaining greater (Accidental) principle ACCEPTANCE VERACODE relevance in the Design and Testing phases. FAILURES / DEPLOYMENT AND Privileges must have a resilient configuration MALFUNCTIONS INTEGRATION - Application Security Verification against unauthorised changes, and must be in line DAMAGE / LOSS MAINTENANCE AND Standard 4.0 (ASVS). OWASP with authorisation and access control policies. DISPOSAL - CSA IoT Security Controls Framework. Cloud Security Alliance (CSA)

- Proactive Controls for developers v3.0. OWASP

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

- SECURE CODING BEST

PRACTICES HANDBOOK.

VERACODE

- BUILDING SECURITY IN

MATURITY MODEL (BSIMM).

BSIMM

- NIST SP 800 53r5: Security and

Privacy Controls for Federal

Information Systems and

Organizations. NIST

- ISO-IEC 27001. ISO

- GSMA IoT Security Assessment

Checklist - Reference CLP12_5

- Application Security Verification

Allocate a project resource (i.e. a data repository) Standard 4.0 (ASVS). OWASP

to centralise security control management REQUIREMENTS - SECURE CODING BEST activities (security control updates, tracking, DESIGN PERSONNEL PRACTICES HANDBOOK. monitoring) to be carried out during the SDLC DEVELOPMENT/IMP UNINTENTIONAL VERACODE process. Verify that the security controls LEMENTATION DAMAGES PR-23. Verify security implemented are accessible, controlled regularly, TESTING AND - The BSA Framework for Secure Security Design (Accidental) controls safe, and reusable, avoiding duplicates and ACCEPTANCE Software. BSA Software Alliance FAILURES / ensuring they are efficient, reliable, and based on DEPLOYMENT AND MALFUNCTIONS - Application Security Verification international best practices. It is recommended to INTEGRATION DAMAGE / LOSS Standard 4.0 (ASVS). OWASP review and update them periodically, at least once MAINTENANCE AND

a year or upon every important change (new DISPOSAL - CSA IoT Security Controls

technologies, project's lessons learned, etc.). Framework. Cloud Security Alliance

(CSA)

- Security for industrial automation

and control systems. Part 4-1:

Secure product development During the Design phase of the SDLC process, lifecycle requirements. IEC 62443solutions must be reviewed from the point of view PERSONNEL 4-1 of security, ensuring that security requirements, UNINTENTIONAL which have been previously defined, have been - "Systems and software engineering DAMAGES PR-24. Perform a design met, identifying the attack surface, carrying out a —Software life cycle processes. Security Design (Accidental) DESIGN review threat modelling, providing security mechanisms, ISO 12207" FAILURES / and scheduling periodic reviews throughout the MALFUNCTIONS - Fundamental Practices for Secure development process based on milestones. It is DAMAGE / LOSS Software Development, recommended to execute this process in every iteration (sprint). SAFECODE

- The BSA Framework for Secure

Software. BSA Software Alliance

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

- NISTIR 8200 - Interagency Report on the Status of International Cybersecurity Standardization for the Internet of Things (IoT). NIST

- MITIGATING THE RISK OF SOFTWARE VULNERABILITIES BY ADOPTING A SECURE SOFTWARE DEVELOPMENT FRAMEWORK (SSDF). NIST

- ISO-IEC 27001. ISO

- BUILDING SECURITY IN MATURITY MODEL (BSIMM). BSIMM

- "Software Assurance Maturity Model (SAMM). OWASP SAMM

- CSA Guidance - CSA"

- GSMA IoT Security Assessment Checklist - Reference CLP11_7

- Proactive Controls for developers v3.0. OWASP Establishing security requirements prior to - Software Assurance Maturity Model development makes it possible to implement (SAMM). OWASP SAMM security functionalities that ensure compliance with standards and laws and avoid known - Fundamental Practices for Secure vulnerabilities. The definition of these security Software Development, requirements makes it possible to industrialise the SAFECODE PERSONNEL security standards that apply to different UNINTENTIONAL - BUILDING SECURITY IN developments, complying with a series of standard DAMAGES MATURITY MODEL (BSIMM). security controls, making it possible to fix past PR-25. Specify security (Accidental) BSIMM Security Design problems, and helping to prevent future flaws. REQUIREMENTS requirements LEGAL Some best practices would be the performance of - MITIGATING THE RISK OF FAILURES / security and requirement compliance SOFTWARE VULNERABILITIES MALFUNCTIONS assessments, the specification of requirements BY ADOPTING A SECURE DAMAGE / LOSS based on known risks, the definition of SOFTWARE DEVELOPMENT requirements in agreement with providers, the FRAMEWORK (SSDF). NIST implementation of security user stories, and the performance of security audits. They must be - CSA IoT Security Controls reviewed periodically, at least every time known Framework. Cloud Security Alliance best practices and regulations are updated. (CSA)

- Application Security Verification Standard 4.0 (ASVS) . OWASP

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

- The BSA Framework for Secure

Software. BSA Software Alliance

- Security for industrial automation

and control systems. Part 4-1:

Secure product development

lifecycle requirements. IEC 62443-

4-1

- ISO-IEC 27001. ISO

- NIST SP 800 53r5: Security and

Privacy Controls for Federal

Information Systems and

Organizations. NIST

- GSMA IoT Security Assessment

Checklist - Reference CLP11_7

- Software Assurance Maturity Model

(SAMM). OWASP SAMM

- The BSA Framework for Secure Identify risks throughout the software development Software. BSA Software Alliance process, analysing the sources, data storage,

applications or third parties. As part of the - CSA IoT Security Controls

analysis, make sure that the data to be protected Framework Cloud Security Alliance

are reliable, and that there are measures in place (CSA)

to prevent the unauthorised access, loss, PERSONNEL destruction or manipulation thereof. A security risk - International Organization for OUTAGES REQUIREMENTS assessment should include: Standardization (ISO). ISO27001 UNINTENTIONAL DESIGN - The analysis of the potential risk if the security of DAMAGES DEVELOPMENT/IMP - "Systems and software engineering each of the following components were (Accidental) LEMENTATION —Software life cycle processes. compromised: sources, storage, sensitive data, PR-26. Perform a risk LEGAL TESTING AND ISO 12207" Security Design applications, data stores, cloud services. assessment PHYSICAL ATTACK ACCEPTANCE - The analysis of data classification mechanisms - Fundamental Practices for Secure FAILURES / DEPLOYMENT AND and data security capabilities in order to protect Software Development, MALFUNCTIONS INTEGRATION sensitive data from unauthorised use, access, SAFECODE NEFARIOUS MAINTENANCE AND loss, destruction or sabotages. ACTIVITY / ABUSE DISPOSAL - BUILDING SECURITY IN - The analysis of the potential for trusted insiders DAMAGE / LOSS MATURITY MODEL (BSIMM). to misuse their privileged access to data. Based on these analyses, implement best BSIMM

practices for the mitigation of each potential - NIST SP 800 53r5: Security and security threat. Privacy Controls for Federal This process must be periodically reviewed, at Information Systems and least once a year. Organizations. NIST

- GSMA IoT Security Assessment

Checklist - Reference CLP11_5

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

- Security Assurance in the SDLC for the Internet of Things - ISACA.

- "Software Assurance Maturity Model (SAMM)

- Open Reference Architecture for Security and Privacy Tactical Threat Modeling Veracode

- OWASP SAMM. Open Reference Architecture for Security and In the software design phase, it is necessary to Privacy study the architecture and the design of the system by means of threat modelling techniques. - Security in the Software Threat modelling thoroughly identifies key assets Development Lifecycle- USENIX " thus far hidden, as well as their associated risks. Through this technique, developers can focus their - Fundamental Practices for Secure Software Development, efforts on subsequent phases, applying tools SAFECODE oriented to the uncovered risks. OUTAGES PR-27. Implement Threat Developers should regard the following aspects as Security Design NEFARIOUS DESIGN - BUILDING SECURITY IN Modelling best practices: ACTIVITY / ABUSE MATURITY MODEL (BSIMM). - Building and maintaining threat models for each BSIMM application, defining the profile of potential attackers by means of the software architecture. - CSA IoT Security Controls - Building and maintaining abuse case models per Framework. Cloud Security Alliance project, establishing threat assessment systems. (CSA) Explicitly evaluate the risk of third-party - Application Security Verification components and generate threat models with Standard 4.0 (ASVS). OWASP security controls. - The BSA Framework for Secure Software. BSA Software Alliance

- Security for industrial automation and control systems. Part 4-1: Secure product development lifecycle requirements. IEC 62443- 4-1

- GSMA IoT Security Assessment Checklist - Reference CLP11_7

Data are a critical asset from the point of view of - Proactive Controls for developers security. PERSONNEL v3.0. OWASP Based on the classification of information (status, FAILURES / PR-28. Implement data REQUIREMENTS Security Design use, owner, risk, etc.), assign a level of sensitivity MALFUNCTIONS - CSA IoT Security Controls classification DESIGN LEGAL to the data in the requirement phase to establish Framework. Cloud Security Alliance DAMAGE / LOSS the corresponding protection measures throughout (CSA) the SDLC process (ensuring the privacy of data at

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

rest by means of encryption, preventing - ISO-IEC 27001. ISO unauthorised access by means of control access, - BUILDING SECURITY IN etc.). MATURITY MODEL (BSIMM). BSIMM

- The BSA Framework for Secure Software. BSA Software Alliance

- Security for industrial automation and control systems. Part 4-1: Secure product development lifecycle requirements. IEC 62443- 4-1

- Application Security Verification Standard 4.0 (ASVS). OWASP

- GSMA IoT Security Assessment Checklist - Reference CLP12_5

- Proactive Controls for developers v3.0. OWASP

- Software Assurance Maturity Model (SAMM). OWASP SAMM

- Fundamental Practices for Secure Software Development, Bear in mind that, as part of the functional SAFECODE requirements, it is essential to take into account the implications for hardware derived from - BUILDING SECURITY IN PERSONNEL PR-29. Ensure that the software security requirements. Implement MATURITY MODEL (BSIMM). UNINTENTIONAL hardware requirements controls during the Requirements phase in order to BSIMM DAMAGES derived from software associate/map software security requirement and (Accidental) - MITIGATING THE RISK OF Security Design requirements are hardware requirements and ultimately fulfil them. REQUIREMENTS LEGAL For instance, associate secure boot mechanisms SOFTWARE VULNERABILITIES considered FAILURES / with the use of chips/modules supporting this BY ADOPTING A SECURE MALFUNCTIONS technology (Root-of-Trust), identifying hardware SOFTWARE DEVELOPMENT DAMAGE / LOSS FRAMEWORK (SSDF). NIST needs based on the communication protocol chosen in order to determine the power source - CSA IoT Security Controls depending on consumption, etc. Framework. Cloud Security Alliance (CSA)

- Application Security Verification Standard 4.0 (ASVS). OWASP

- The BSA Framework for Secure Software. BSA Software Alliance

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

- Security for industrial automation and control systems. Part 4-1: Secure product development lifecycle requirements. IEC 62443- 4-1

- ISO-IEC 27001. ISO

- NIST SP 800 53r5: Security and Privacy Controls for Federal Information Systems and Organizations. NIST

- GSMA IoT Security Assessment Checklist - Reference CLP11_7

- The BSA Framework for Secure Software. BSA Software Alliance

- MITIGATING THE RISK OF SOFTWARE VULNERABILITIES BY ADOPTING A SECURE SOFTWARE DEVELOPMENT FRAMEWORK (SSDF). NIST PERSONNEL Develop a communication plan targeted at all REQUIREMENTS - Fundamental Practices for Secure UNINTENTIONAL persons involved in the development process DESIGN Software Development, DAMAGES (specially third-parties) in order to report on the DEVELOPMENT/IMP SAFECODE (Accidental) security measures that must be observed for a LEMENTATION PR-30. Establish a LEGAL proper development, such as applicable TESTING AND - Software Assurance Maturity Model Internal Policies communication plan for PHYSICAL ATTACK regulations, security frameworks and ACCEPTANCE (SAMM 1.5v). OWASP security measures FAILURES / methodologies to be used, security best practices, DEPLOYMENT AND MALFUNCTIONS etc. This plan must be reviewed, validated and INTEGRATION - Recommended Security Controls NEFARIOUS disseminated in the organisation at least once a MAINTENANCE AND ACTIVITY / ABUSE for Federal Information Systems year. DISPOSAL DAMAGE / LOSS and Organizations. NIST 800-53

- "Information technology — Security techniques — Information security management systems — Requirements. ISO 27001"

- BUILDING SECURITY IN MATURITY MODEL (BSIMM). BSIMM

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

- The BSA Framework for Secure

Software. BSA Software Alliance.

- Proactive Controls for developers

PERSONNEL v3.0. OWASP.

UNINTENTIONAL REQUIREMENTS Ensure that process information is not disclosed or - Security for industrial automation DAMAGES DESIGN tampered with by any stakeholder throughout the and control systems. Part 4-1: DEVELOPMENT/IMP lifecycle without prior authorisation, as it could (Accidental) LEMENTATION Secure product development PR-31. Control the process result in a compromise of intellectual property, a TESTING AND lifecycle requirements. IEC 62443- Internal Policies against information breach of regulatory compliance, reputational LEGAL ACCEPTANCE disclosure losses, etc. Security measures should be 4-1 FAILURES / DEPLOYMENT AND considered such as role-based access control, MALFUNCTIONS INTEGRATION - "Information technology- Security authorisation, permission assignment, non- NEFARIOUS MAINTENANCE AND disclosure clauses in the contracts, etc. techniques - Information security ACTIVITY / ABUSE DISPOSAL management systems - DAMAGE / LOSS Requirements. ISO 27001"

- Recommended Security Controls

for Federal Information Systems

and Organizations. NIST 800-53

- Application Security Verification

Standard 4.0 (ASVS). OWASP

- The BSA Framework for Secure

Software. BSA Software Alliance

- CSA IoT Security Controls

PERSONNEL REQUIREMENTS Framework. Cloud Security Alliance

UNINTENTIONAL DESIGN (CSA) Ensure the availability of security policies, DAMAGES DEVELOPMENT/IMP procedures, guides, applicable regulations and (Accidental) LEMENTATION - Security for industrial automation PR-32. Verify and ensure requirements for developers. Throughout the LEGAL TESTING AND and control systems. Part 4-1: Internal Policies the availability of updated process, a centralised repository must be FAILURES / ACCEPTANCE security documents accessible. Organisations have to implement Secure product development MALFUNCTIONS DEPLOYMENT AND change management to guarantee the integrity of lifecycle requirements. IEC 62443- NEFARIOUS INTEGRATION data and avoid introducing errors in the process. 4-1 ACTIVITY / ABUSE MAINTENANCE AND

DAMAGE / LOSS DISPOSAL - "Information technology — Security

techniques — Information security

management systems —

Requirements. ISO 27001"

- Proactive Controls for developers

v3.0. OWASP

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

- "Systems and software engineering -Software life cycle processes. ISO 12207"

- Recommended Security Controls for Federal Information Systems and Organizations. NIST 800-53

- Software Assurance Maturity Model (SAMM). OWASP SAMM

- "Information technology — Security techniques — Information security management systems — PERSONNEL REQUIREMENTS Requirements. ISO 27001" OUTAGES DESIGN - "Systems and software engineering Distribute your resources so as to not centralise UNINTENTIONAL —Software life cycle processes. security knowledge in a single resource, be it DAMAGES DEVELOPMENT/IMP ISO 12207" internal or through a third party, with a view to avoiding cases of unavailability that may bring the (Accidental) LEMENTATION PR-33. Plan an alternative secure development (sSDLC) process to a - Recommended Security Controls Internal Policies LEGAL TESTING AND for unavailability cases standstill in any of the phases. This would be the for Federal Information Systems case, for instance, when there is only one security ACCEPTANCE and Organizations. NIST 800-53 FAILURES / pentesting specialist during the Testing phase. This measure focuses on providing an alternative MALFUNCTIONS DEPLOYMENT AND - Software Assurance Maturity Model for SDLC critical points (resources redundancy). INTEGRATION (SAMM). OWASP SAMM NEFARIOUS ACTIVITY / ABUSE MAINTENANCE AND - Security for industrial automation DISPOSAL and control systems. Part 4-1: DAMAGE / LOSS Secure product development lifecycle requirements. IEC 62443- 4-1

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

4.5 TECHNOLOGIES

SSDLC phases Security domain Title Description Threats Reference title involved

- The BSA Framework for Secure Software. BSA Software Alliance

- Proactive Controls for developers v3.0. OWASP

- Security Assurance in the SDLC for the Internet of Things - ISACA. ISACA

- MITIGATING THE RISK OF SOFTWARE VULNERABILITIES Implement access control in IoT systems and BY ADOPTING A SECURE software to ensure that the system verifies that SOFTWARE DEVELOPMENT users and applications have the right permissions PERSONNEL FRAMEWORK (SSDF). NIST allocated to their roles to access system PHYSICAL ATTACK REQUIREMENTS resources. This can be done by means of the least LEGAL DESIGN - CSA IoT Security Controls TC-01. Implement privilege principle and a strategy regarding FAILURES / DEVELOPMENT/IMP Framework. Cloud Security Alliance Access Control authorisation policies, controls, and design (CSA) authorisation MALFUNCTIONS LEMENTATION principles for different categories of data. NEFARIOUS DEPLOYMENT AND - Application Security Verification If a password is being used for authentication, the ACTIVITY / ABUSE INTEGRATION Standard 4.0 (ASVS). OWASP asset should force the user to change the DAMAGE / LOSS - NIST SP 800 53r5: Security and password at first use. Furthermore, typed Privacy Controls for Federal characters should be masked. Information Systems and Organizations. NIST

- ISO-IEC 27001. ISO

- SECURE CODING BEST PRACTICES HANDBOOK. VERACODE

- GSMA IoT Security Assessment Checklist - Reference CLP12_5 and CLP13_6

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

- SECURE CODING BEST PRACTICES HANDBOOK. VERACODE

- Proactive Controls for developers v3.0. OWASP

- CSA IoT Security Controls Framework. Cloud Security Alliance (CSA)

Ensure that user credentials of IoT systems (and - Application Security Verification other underlying infrastructure) are secured. Standard 4.0 (ASVS). OWASP Passwords must always be hashed with a salt. DEPLOYMENT AND - The BSA Framework for Secure Password bolts are often used to hard code FAILURES / TC-02. Secure storage of INTEGRATION Software. BSA Software Alliance Access Control credentials for system communications, so that the MALFUNCTIONS users' credentials MAINTENANCE AND system has to request the credentials before NEFARIOUS - Security for industrial automation DISPOSAL accessing a resource. This measure prevents to ACTIVITY / ABUSE and control systems. Part 4-1: access to sensitive functionalities and data (e.g. DAMAGE / LOSS Secure product development source code). lifecycle requirements. IEC 62443- 4-1

- ISO-IEC 27001. ISO

- NIST SP 800 53r5: Security and Privacy Controls for Federal Information Systems and Organizations. NIST

- GSMA IoT Security Assessment Checklist - Reference CLP11_6

- MITIGATING THE RISK OF SOFTWARE VULNERABILITIES PERSONNEL BY ADOPTING A SECURE Systems and their corresponding hardware must REQUIREMENTS OUTAGES SOFTWARE DEVELOPMENT be protected against unauthorised modification DESIGN PHYSICAL ATTACK FRAMEWORK (SSDF). NIST attempts and direct access, as well as other DEVELOPMENT/IMP LEGAL Access Control TC-03. Deploy physical dangers (fire, water, cooling issues, etc.). Physical LEMENTATION - Security Design Principles. FAILURES / protection for systems access must be controlled and unused physical DEPLOYMENT AND OWASP MALFUNCTIONS interfaces must be disabled or inaccessible. INTEGRATION NEFARIOUS - Security for industrial automation Removing unnecessary items helps to reduce the MAINTENANCE AND ACTIVITY / ABUSE and control systems. Part 4-1: attack surface. DISPOSAL DAMAGE / LOSS Secure product development lifecycle requirements. IEC 62443- 4-1

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

- CSA IoT Security Controls Framework. Cloud Security Alliance (CSA)

- Application Security Verification Standard 4.0 (ASVS). OWASP

- ISO-IEC 27001. ISO

- NIST SP 800 53r5: Security and Privacy Controls for Federal Information Systems and Organizations. NIST

- The BSA Framework for Secure Software. BSA Software Alliance

- GSMA IoT Security Assessment Checklist - Reference CLP13_7

- Application Security Verification Standard 4.0 (ASVS). OWASP

Ensure the secure management of service - CSA IoT Security Controls credentials for your SDLC systems, especially in FAILURES / DESIGN Framework. Cloud Security Alliance TC-04. Implement Key (CSA) the context of web and cloud services. They must MALFUNCTIONS DEPLOYMENT AND

management and

Access Control be temporary and single-use, and the right NEFARIOUS INTEGRATION - CSA IoT Security Controls

authentication mechanisms

communication privileges have to be allocated for ACTIVITY / ABUSE MAINTENANCE AND Framework. Cloud Security Alliance

(e.g. FIDO)

the different service credentials (e.g. user DAMAGE / LOSS DISPOSAL (CSA) credentials vs. System credentials). - GSMA IoT Security Assessment Checklist - Reference CLP12_5 and CLP13_6

- The BSA Framework for Secure Implement a physical access control system with PERSONNEL Software. BSA Software Alliance authorisation mechanisms to identify users and OUTAGES their privileges. This system should be monitored UNINTENTIONAL - Fundamental Practices for Secure and provide event logs for all accesses, including DAMAGES Software Development, unauthorised access attempts. The access to (Accidental) SAFECODE TC-05. Control the physical physical facilities storing information concerning PHYSICAL ATTACK - Proactive Controls for developers Access Control access to the critical the SDLC or systems that support the process LEGAL REQUIREMENTS (repositories, network equipment, documentation v3.0. OWASP facilities FAILURES / files, etc.) must be adequately protected. This MALFUNCTIONS - Application Security Verification measure can be stipulated in contracts with NEFARIOUS Standard 4.0 (ASVS) . OWASP external providers concerning the control of ACTIVITY / ABUSE facilities containing information about the service - CSA IoT Security Controls hired. Additionally, a CCTV surveillance system DAMAGE / LOSS Framework. Cloud Security Alliance could be configured to communicate with an alarm (CSA)

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

system (e.g. SIEM) and send signals alerting to - SECURE CODING BEST unauthorised access attempts. PRACTICES HANDBOOK. VERACODE

- MITIGATING THE RISK OF SOFTWARE VULNERABILITIES BY ADOPTING A SECURE SOFTWARE DEVELOPMENT FRAMEWORK (SSDF). NIST

- Security for industrial automation and control systems. Part 4-1: Secure product development lifecycle requirements. IEC 62443- 4-1

- NISTIR 8200 - Interagency Report on the Status of International Cybersecurity Standardization for the Internet of Things (IoT). NIST

- NIST SP 800 53r5: Security and Privacy Controls for Federal Information Systems and Organizations. NIST

- ISO-IEC 27001. ISO

- CSA IoT Security Controls Framework. Cloud Security Alliance (CSA)

- Application Security Verification Standard 4.0 (ASVS). OWASP

Ensure that your SDLC model enforces the use of DESIGN - Proactive Controls for developers the latest versions of third-party libraries to FAILURES / DEVELOPMENT/IMP v3.0. OWASP TC-06. Use libraries and safeguard their integrity. The most costly and MALFUNCTIONS LEMENTATION - SECURE CODING BEST

Third-Party third-party component that

extensive attacks have been caused by this issue. NEFARIOUS TESTING AND PRACTICES HANDBOOK.

Software are patched for latest

Check the versions of your dependencies at least ACTIVITY / ABUSE ACCEPTANCE known vulnerabilities VERACODE quarterly once the software under construction is DAMAGE / LOSS MAINTENANCE AND in production. DISPOSAL - Software Assurance Maturity Model (SAMM). OWASP SAMM

- MITIGATING THE RISK OF SOFTWARE VULNERABILITIES BY ADOPTING A SECURE SOFTWARE DEVELOPMENT FRAMEWORK (SSDF). NIST

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

- The BSA Framework for Secure Software. BSA Software Alliance

- Security for industrial automation and control systems. Part 4-1: Secure product development lifecycle requirements. IEC 62443- 4-1

- The BSA Framework for Secure Software. BSA Software Alliance

- Proactive Controls for developers v3.0. OWASP

- CSA IoT Security Controls Framework. Cloud Security Alliance (CSA)

- NIST SP 800 53r5: Security and For the foundation technologies of the software Privacy Controls for Federal under development, use and verify known software Information Systems and security frameworks from third party providers Organizations. NIST supplying LTS (Long Time Support) or similar. - SECURE CODING BEST Some software have associated security flaws, so PRACTICES HANDBOOK. it is essential to make sure that these components FAILURES / TC-07. Use known secure DESIGN VERACODE Third-Party can be trusted in the long term. MALFUNCTIONS frameworks with long-term DEVELOPMENT/IMP Software NEFARIOUS support LEMENTATION - Fundamental Practices for Secure These components should be chosen considering ACTIVITY / ABUSE Software Development, if they are maintained by a private organisation or DAMAGE / LOSS SAFECODE an active group, if security patches are available in short time when a vulnerability is disclosed and if - MITIGATING THE RISK OF developers can be contacted if a vulnerability is SOFTWARE VULNERABILITIES identified. BY ADOPTING A SECURE SOFTWARE DEVELOPMENT FRAMEWORK (SSDF). NIST

- Application Security Verification Standard 4.0 (ASVS) . OWASP

- ISO-IEC 27001. ISO

- CSA IoT Security Controls Framework. Cloud Security Alliance (CSA)

PERSONNEL REQUIREMENTS Secure TC-08. Use secure Ensure that communications are always encrypted NEFARIOUS - Application Security Verification DESIGN Communication communication protocols between IoT systems and the underlying ACTIVITY / ABUSE Standard 4.0 (ASVS). OWASP DEVELOPMENT/IMP infrastructure they are integrated. Additionally, it is DAMAGE / LOSS LEMENTATION

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

also recommended to implement mechanisms to TESTING AND - NISTIR 8200 - Interagency Report authenticate communications. ACCEPTANCE on the Status of International DEPLOYMENT AND Cybersecurity Standardization for INTEGRATION the Internet of Things (IoT). NIST MAINTENANCE AND - Proactive Controls for developers DISPOSAL v3.0. OWASP

- Security Assurance in the SDLC for the Internet of Things - ISACA. ISACA

- Security for industrial automation and control systems. Part 4-1: Secure product development lifecycle requirements. IEC 62443- 4-1

- The BSA Framework for Secure Software. BSA Software Alliance

- ISO-IEC 27001. ISO

- NIST SP 800 53r5: Security and Privacy Controls for Federal Information Systems and Organizations. NIST

- CSA IoT Security Controls Framework. Cloud Security Alliance (CSA)

- GSMA IoT Security Assessment Checklist - Reference CLP12_6 and CLP13_6

In any IoT system, data must be encrypted, both at - SECURE CODING BEST rest and in transit, using a recognised encryption REQUIREMENTS PRACTICES HANDBOOK. algorithm. However, even resilient algorithms are DESIGN VERACODE not efficient if they are not properly used (e.g. DEVELOPMENT/IMP sufficient key length). It is necessary to use an LEMENTATION - Application Security Verification LEGAL Secure TC-09. Use proven initialisation vector and to guarantee a minimum TESTING AND Standard 4.0 (ASVS). OWASP NEFARIOUS Communication encryption techniques level of entropy. It is highly recommended to apply ACCEPTANCE ACTIVITY / ABUSE - Proactive Controls for developers hashes to protect electronic signatures. These DEPLOYMENT AND DAMAGE / LOSS measures apply both to original data and to any INTEGRATION v3.0. OWASP existing backups. Potential legal consequences MAINTENANCE AND - The BSA Framework for Secure may arise if due diligence it is not in place for data DISPOSAL Software. BSA Software Alliance protection.

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

- BUILDING SECURITY IN MATURITY MODEL (BSIMM). BSIMM

- Security Assurance in the SDLC for the Internet of Things - ISACA. ISACA

- MITIGATING THE RISK OF SOFTWARE VULNERABILITIES BY ADOPTING A SECURE SOFTWARE DEVELOPMENT FRAMEWORK (SSDF). NIST

- Fundamental Practices for Secure Software Development, SAFECODE

- Security for industrial automation and control systems. Part 4-1: Secure product development lifecycle requirements. IEC 62443- 4-1

- NIST SP 800 53r5: Security and Privacy Controls for Federal Information Systems and Organizations. NIST

- ISO-IEC 27001. ISO

- CSA IoT Security Controls Framework. Cloud Security Alliance (CSA)

- Application Security Verification Standard 4.0 (ASVS). OWASP REQUIREMENTS - Security for industrial automation DESIGN Any web interface of IoT components must and control systems. Part 4-1: DEVELOPMENT/IMP implement technical measures to reduce the Secure product development FAILURES / LEMENTATION exposure of management interfaces and detect lifecycle requirements. IEC 62443- Secure TC-10. Implement secure MALFUNCTIONS TESTING AND potential unauthorised accesses, making the web 4-1 Communication web interfaces NEFARIOUS ACCEPTANCE interfaces hard to use for an attacker. This ACTIVITY / ABUSE DEPLOYMENT AND - CSA IoT Security Controls measure prevents the access to sensitive DAMAGE / LOSS INTEGRATION Framework. Cloud Security Alliance functionalities and data (e.g. source code). MAINTENANCE AND (CSA) DISPOSAL - GSMA IoT Security Assessment Checklist - Reference CLP12_5

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

- Application Security Verification

Standard 4.0 (ASVS). OWASP

- Security Assurance in the SDLC for the Internet of Things - ISACA.

ISACA

For all sessions that take place in IoT, it is - SECURE CODING BEST essential to ensure that active sessions are unique PRACTICES HANDBOOK. and cannot be shared or guessed, and that they FAILURES / DESIGN VERACODE are timed out and invalidated when no longer MALFUNCTIONS DEVELOPMENT/IMP Secure TC-11. Implement secure necessary. Session tokens should be unique for - NIST SP 800 53r5: Security and NEFARIOUS LEMENTATION Communication session management each session, guaranteeing a minimum level of Privacy Controls for Federal ACTIVITY / ABUSE TESTING AND entropy. They must never be disclosed in URLs or Information Systems and DAMAGE / LOSS ACCEPTANCE error messages. Cookie-based sessions must Organizations. NIST

have the 'Secure', 'SameSite', and 'HttpOnly' attributes enabled. - ISO-IEC 27001. ISO

- Proactive Controls for developers

v3.0. OWASP

- GSMA IoT Security Assessment

Checklist - Reference CLP12_5

and CLP13_6

- The BSA Framework for Secure In the SDLC process, secure coding practices Software. BSA Software Alliance must be implemented during different phases,

including at least: - Application Security Verification

Proven strong authentication mechanism to Standard 4.0 (ASVS). OWASP

access the software (e.g. two-factor authentication, - Proactive Controls for developers minimum password length, secure transfer, secure v3.0. OWASP connection, secure credential management, etc.). UNINTENTIONAL REQUIREMENTS - Security Assurance in the SDLC for DAMAGES Handling all errors and anomalous conditions that DESIGN the Internet of Things - ISACA. can compromise of sensitive information about the (Accidental) DEVELOPMENT/IMP ISACA TC-12. Implement secure application PERSONNEL LEMENTATION Secure Code - Fundamental Practices for Secure coding practices PHYSICAL ATTACK DEPLOYMENT AND Parameterisation of queries by binding the LEGAL INTEGRATION Software Development, variables in the corresponding languages to SAFECODE FAILURES / prevent code injections in the query language, and TESTING AND MALFUNCTIONS - CSA IoT Security Controls Validation of input and output for forms’ NEFARIOUS ACCEPTANCE Framework. Cloud Security Alliance submissions such as with respect to language, ACTIVITY / ABUSE (CSA) characters, etc. (e.g. whitelisting mechanisms). DAMAGE / LOSS These should be addressed in the SDLC to ensure - Security for industrial automation

the design, implementation and testing take this and control systems. Part 4-1:

into account. Secure product development

lifecycle requirements. IEC 62443-

4-1

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

- ISO-IEC 27001. ISO

- NIST SP 800 53r5: Security and Privacy Controls for Federal Information Systems and Organizations. NIST

- SECURE CODING BEST PRACTICES HANDBOOK. VERACODE

- "Systems and software engineering -Software life cycle processes. ISO 12207"

- MITIGATING THE RISK OF SOFTWARE VULNERABILITIES BY ADOPTING A SECURE SOFTWARE DEVELOPMENT FRAMEWORK (SSDF). NIST

- GSMA IoT Security Assessment Checklist - Reference CLP13_6

- SECURE CODING BEST PRACTICES HANDBOOK. VERACODE

- The BSA Framework for Secure Software. BSA Software Alliance REQUIREMENTS DESIGN - Application Security Verification Your SDLC model must ensure that the software Standard 4.0 (ASVS). OWASP UNINTENTIONAL DEVELOPMENT/IMP under development (and IoT systems) include non- DAMAGES LEMENTATION repudiation features (design, implementation, - Fundamental Practices for Secure TC-13. Provide audit (Accidental) TESTING AND Secure Code testing, etc.). High-value functionalities must be Software Development, capability PHYSICAL ATTACK ACCEPTANCE tracked to control critical aspects of the software. SAFECODE LEGAL DEPLOYMENT AND This could be mandatory, or highly advisable for NEFARIOUS INTEGRATION - ISO-IEC 27001. ISO regulatory compliance. ACTIVITY / ABUSE MAINTENANCE AND DISPOSAL - NIST SP 800 53r5: Security and Privacy Controls for Federal Information Systems and Organizations. NIST

- GSMA IoT Security Assessment Checklist - Reference CLP11_7

TC-14. Follow the principles Many decisions are made during the design PERSONNEL DESIGN Secure Code of security by design and - STRATEGIC PRINCIPLES FOR phase, when the final functionality of the solution is UNINTENTIONAL DEVELOPMENT/IMP by default SECURING THE INTERNET OF devised, including access verifications. These DAMAGES LEMENTATION

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

decisions apply to the entire scope of the SDLC, (Accidental) TESTING AND THINGS (IoT). U.S. Department of implemented in the implementation/development FAILURES / ACCEPTANCE Homeland Security phase, and tested before and after the production MALFUNCTIONS environment. The fail-safe principle must be taken NEFARIOUS - Application Security Verification into account to prepare the device for errors, ACTIVITY / ABUSE Standard 4.0 (ASVS). OWASP anticipate potential disruptions of the service, and DAMAGE / LOSS - Security Design Principles. respond appropriately to ensure recovery. The OWASP principle of least privilege must also be observed to prevent unnecessary or unauthorised accesses. - Proactive Controls for developers This set of measures is aimed at safeguarding v3.0. OWASP data from being compromised. - Security Assurance in the SDLC for Implement strong user authentication by enforcing the Internet of Things - ISACA. the change of passwords upon first use, and the ISACA periodic renewal of passwords (e.g. at least once - CSA IoT Security Controls in 90 days to every 6 months) and session / time Framework. Cloud Security Alliance lockout upon multiple failed authentication (CSA) attempts (password, or other). - ISO-IEC 27001. ISO

- Security for industrial automation and control systems. Part 4-1: Secure product development lifecycle requirements. IEC 62443- 4-1

- SECURE CODING BEST PRACTICES HANDBOOK.

- Application Security Verification Use development techniques that make Standard 4.0 (ASVS). application architecture more flexible. Modular REQUIREMENTS - Proactive Controls for developers architectures provide great benefits, not only DESIGN v3.0. during the operation to speed up updates or DEVELOPMENT/IMP identify and troubleshoot, but during development. LEMENTATION - The BSA Framework for Secure LEGAL Developing large and indivisible blocks implies TESTING AND Software. TC-15. Implement software NEFARIOUS Secure Code having a large team and making it difficult to define ACCEPTANCE development techniques ACTIVITY / ABUSE the scope. However, using techniques such as DEPLOYMENT AND - BUILDING SECURITY IN INTEGRATION MATURITY MODEL (BSIMM). micro-services, a large block can be broken down DAMAGE / LOSS into several to make the development agile, - Security Assurance in the SDLC for MAINTENANCE AND increase flexibility and scalability, facilitate the the Internet of Things - ISACA. DISPOSAL definition of scopes and functionalities, and decrease errors. - MITIGATING THE RISK OF SOFTWARE VULNERABILITIES BY ADOPTING A SECURE SOFTWARE DEVELOPMENT FRAMEWORK (SSDF).

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

- SAFECode_Fundamental_Practice s_forSDLC.

- Security for industrial automation and control systems. Part 4-1: Secure product development lifecycle requirements.

- NIST SP 800 53r5: Security and Privacy Controls for Federal Information Systems and Organizations.

- ISO-IEC 27001.

- CSA IoT Security Controls Framework.

- Application Security Verification Standard 4.0 (ASVS). OWASP.

- CSA IoT Security Controls Framework. Cloud Security Alliance Ensure that production code comes with secure (CSA). compiler options (compiled with security flags) and PERSONNEL - ISO-IEC 27001. ISO. does not contain forgotten debug code or debug FAILURES / DEVELOPMENT/IMP TC-16. Verify production symbols. - NIST SP 800 53r5: Security and MALFUNCTIONS LEMENTATION

Secure Code

code NEFARIOUS TESTING AND Privacy Controls for Federal At production environment, security is crucial and it ACTIVITY / ABUSE ACCEPTANCE Information Systems and must be carefully controlled by ensuring not only DAMAGE / LOSS Organizations. NIST. the integrity of the tools but person competence conducting these activities. - BUILDING SECURITY IN MATURITY MODEL (BSIMM). BSIMM.

- Application Security Verification Standard 4.0 (ASVS). OWASP.

Patches must be carefully managed and deployed - Application Security Verification to prevent additional issues with update Standard 4.0 (ASVS). OWASP capabilities. It is necessary to ensure that all IoT elements can be updated and patched, and - Security for industrial automation LEGAL and control systems. Part 4-1: TC-17. Ensure security for developers enable notifications of updates and MAINTENANCE AND Security Code NEFARIOUS patches and updates security patches so that users can receive them for DISPOSAL Secure product development ACTIVITY / ABUSE lifecycle requirements. IEC 62443having information if, when and how patch software. The installation of security patches and 4-1 updates should be user-friendly (e.g. automatic or - NISTIR 8200 - Interagency Report in a few clicks). on the Status of International

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

Update mechanisms include secure/encrypted Cybersecurity Standardization for delivery of updates, validation of signatures on the the Internet of Things (IoT). NIST device before installing the patch (secure boot), - MITIGATING THE RISK OF etc. SOFTWARE VULNERABILITIES Secure over-the-air updates should be considered BY ADOPTING A SECURE through a secure mechanism that is SOFTWARE DEVELOPMENT cryptographically signed. This must be considered FRAMEWORK (SSDF). NIST for all IoT systems, as well as for the software under construction already in production (patching - BUILDING SECURITY IN MATURITY MODEL (BSIMM). as soon as possible for critical vulnerabilities). This BSIMM measure prevents CVEs exploited by threat agents, and potential legal consequences may - CSA IoT Security Controls arise if due diligence is not in place to keep the Framework. Cloud Security Alliance systems in a well-fit state. (CSA)

- NIST SP 800 53r5: Security and Privacy Controls for Federal Information Systems and Organizations. NIST

- The BSA Framework for Secure Software. BSA Software Alliance

- ISO-IEC 27001. ISO

- MITIGATING THE RISK OF SOFTWARE VULNERABILITIES BY ADOPTING A SECURE SOFTWARE DEVELOPMENT FRAMEWORK (SSDF). NIST

- GSMA IoT Security Assessment Checklist - Reference CLP12_6

- Application Security Verification Standard 4.0 (ASVS). OWASP Ensure malicious code is adequately managed (perform manual reviews, protect the code - CSA IoT Security Controls PERSONNEL repository against tampering, etc.) in your SDLC Framework. Cloud Security Alliance FAILURES / DEVELOPMENT/IMP TC-18. Implement measures model. Validate the application source code and (CSA) MALFUNCTIONS LEMENTATION Secure Code against rogue code and third-party libraries (e.g. lack of backdoors, time NEFARIOUS TESTING AND fraud detection bombs), and that the application does not grant - ISO-IEC 27001. ISO ACTIVITY / ABUSE ACCEPTANCE unnecessary permissions. This measure includes DAMAGE / LOSS - NIST SP 800 53r5: Security and the review of all changes before the deployment of Privacy Controls for Federal the change. Information Systems and Organizations. NIST

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

- BUILDING SECURITY IN MATURITY MODEL (BSIMM). BSIMM

- Application Security Verification Standard 4.0 (ASVS). OWASP

- The BSA Framework for Secure Software. BSA Software Alliance

- CSA IoT Security Controls Framework. Cloud Security Alliance (CSA)

- MITIGATING THE RISK OF SOFTWARE VULNERABILITIES BY ADOPTING A SECURE SOFTWARE DEVELOPMENT FRAMEWORK (SSDF). NIST REQUIREMENTS - Proactive Controls for developers There must be logical tamperproof measures in DESIGN UNINTENTIONAL v3.0. OWASP IoT systems, that is, measures to monitor and DEVELOPMENT/IMP DAMAGES ensure that the most critical assets (e.g. code) LEMENTATION - Security Assurance in the SDLC for (Accidental) TC-19. Implement anti- have not been tampered with (e.g. code-signing). TESTING AND the Internet of Things - ISACA. Secure Code FAILURES / tampering features Tampering could ease the access to sensitive ACCEPTANCE ISACA MALFUNCTIONS functionalities or data for threat agents, and allow DEPLOYMENT AND NEFARIOUS - NIST SP 800 53r5: Security and the insertion of rogue code in the software under INTEGRATION ACTIVITY / ABUSE Privacy Controls for Federal construction. MAINTENANCE AND DAMAGE / LOSS Information Systems and DISPOSAL Organizations. NIST

- Application Security Verification Standard 4.0 (ASVS) . OWASP

- Security for industrial automation and control systems. Part 4-1: Secure product development lifecycle requirements. IEC 62443- 4-1

- GSMA IoT Security Assessment Checklist - Reference CLP13_6

Ensure that your SDLC model includes source - SECURE CODING BEST code reviews. Code reviews can be manual or PERSONNEL DEVELOPMENT/IMP PRACTICES HANDBOOK. TC-20. Apply secure code automated. Good practices recommend NEFARIOUS LEMENTATION Security Reviews VERACODE review performing it manually for each candidate release ACTIVITY / ABUSE TESTING AND (i.e. a member of the development team reviews DAMAGE / LOSS ACCEPTANCE - Software Assurance Maturity Model what another team member has developed to (SAMM). OWASP SAMM ensure quality and share knowledge about the

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

development with the team). This is the only tool - MITIGATING THE RISK OF available to detect malicious code. Automated SOFTWARE VULNERABILITIES code reviews are commonplace and more cost- BY ADOPTING A SECURE effective compared to manual ones. SOFTWARE DEVELOPMENT FRAMEWORK (SSDF). NIST

- Fundamental Practices for Secure Software Development, SAFECODE

- Security Assurance in the SDLC for the Internet of Things - ISACA. ISACA

- Security for industrial automation and control systems. Part 4-1: Secure product development lifecycle requirements. IEC 62443- 4-1

- ISO-IEC 27001. ISO

- BUILDING SECURITY IN MATURITY MODEL (BSIMM). BSIMM

- Application Security Verification Standard 4.0 (ASVS). OWASP

- The BSA Framework for Secure Software. BSA Software Alliance

- Security for industrial automation and control systems. Part 4-1: Secure product development lifecycle requirements. IEC 62443- Carry out this activity during the design phase to 4-1 detect any potential threats resulting from weaknesses. Ensure that your SDLC model - Software Assurance Maturity Model includes this activity to provide value in other (SAMM). OWASP SAMM TC-21. Perform an attack NEFARIOUS Security Reviews phases. It ensures the control of what is DESIGN surface analysis ACTIVITY / ABUSE - Proactive Controls for developers susceptible to be misused in the software under DAMAGE / LOSS v3.0. OWASP development, as well as of potential entry points. It helps to avoid unauthorised activities and data - ISO-IEC 27001. ISO leakages. - NIST SP 800 53r5: Security and Privacy Controls for Federal Information Systems and Organizations. NIST

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

- The BSA Framework for Secure Software. BSA Software Alliance

- GSMA IoT Security Assessment Checklist - Reference CLP11_5

- Security for industrial automation and control systems. Part 4-1: Secure product development lifecycle requirements. IEC 62443- 4-1

- BUILDING SECURITY IN MATURITY MODEL (BSIMM). BSIMM

- MITIGATING THE RISK OF SOFTWARE VULNERABILITIES BY ADOPTING A SECURE SOFTWARE DEVELOPMENT FRAMEWORK (SSDF). NIST

- Fundamental Practices for Secure Ensure that your SDLC model makes software TESTING AND Software Development, undergo testing prior to production to ensure it has FAILURES / ACCEPTANCE SAFECODE no vulnerabilities before deployment. This can be TC-22. Perform IoT SDLC MALFUNCTIONS DEPLOYMENT AND Security Reviews done by means of an audit, and it should be - Security Assurance in the SDLC for tests NEFARIOUS INTEGRATION performed at least, annually (for software under the Internet of Things - ISACA. ACTIVITY / ABUSE MAINTENANCE AND construction and IoT systems) or for each ISACA DAMAGE / LOSS DISPOSAL candidate release. - NIST SP 800 53r5: Security and Privacy Controls for Federal Information Systems and Organizations. NIST

- BUILDING SECURITY IN MATURITY MODEL (BSIMM). BSIMM

- Application Security Verification Standard 4.0 (ASVS). OWASP

- The BSA Framework for Secure Software. BSA Software Alliance

- GSMA IoT Security Assessment Checklist - Reference CLP13_7

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

PERSONNEL Take into consideration contingency plans OUTAGES REQUIREMENTS designed to be integrated into the SDLC. Some UNINTENTIONAL DESIGN - ISO-IEC 27001. ISO activities of the contingency plan, such as the DAMAGES DEVELOPMENT/IMP development of contingency planning policy and - CSA IoT Security Controls (Accidental) LEMENTATION completion of the business impact analysis, must Framework. Cloud Security Alliance PHYSICAL ATTACK TESTING AND TC-23. Design a be executed in the initial phase of the SDLC. (CSA) Security Reviews LEGAL ACCEPTANCE contingency plan However, all the activities of the contingency plan FAILURES / DEPLOYMENT AND - NIST SP 800 53r5: Security and are involved in all the SDLC phases but the last MALFUNCTIONS INTEGRATION one, since once the system is operational, the Privacy Controls for Federal NEFARIOUS Information Systems and contingency planning becomes a core part of MAINTENANCE AND ACTIVITY / ABUSE Organizations. NIST continuous supervision and other ongoing security DISPOSAL

management tasks. DAMAGE / LOSS

- MITIGATING THE RISK OF SOFTWARE VULNERABILITIES

BY ADOPTING A SECURE

SOFTWARE DEVELOPMENT

FRAMEWORK (SSDF). NIST

Implement a system to monitor the requirements - SECURE CODING BEST

agreed by contracts. During the SDLC, a partial or PRACTICES HANDBOOK. OUTAGES full breach of compliance with a requirement is a VERACODE UNINTENTIONAL critical aspect. It would entail an increase in the DAMAGES - Software Assurance Maturity Model TC-24. Monitor project vulnerabilities and might even lead the (Accidental) Security Reviews requirements to ensure the project to fail. It is essential to perform a correct (SAMM 1.5v). OWASP LEGAL REQUIREMENTS SDLC success follow-up of the level of compliance reached by the - The BSA Framework for Secure requirements. To this end, key compliance FAILURES / Software. BSA Software Alliance indicators can be used (regarding quality, result MALFUNCTIONS required, scope, etc.) by means of a requirement - Security for industrial automation

matrix. and control systems. Part 4-1:

Secure product development

lifecycle requirements. IEC 62443-

4-1

- The BSA Framework for Secure

Software. BSA Software Alliance

The software under construction and the IoT systems have to generate high-quality logs, REQUIREMENTS - Proactive Controls for developers PERSONNEL preventing the inclusion of sensitive information. DESIGN v3.0. OWASP PHYSICAL ATTACK Logs have to be monitored (if possible, in real time DEVELOPMENT/IMP TC-25. Ensure secure FAILURES / - Application Security Verification Security of SDLC using automatic systems) and, reviewed and LEMENTATION Logging and Monitoring MALFUNCTIONS Standard 4.0 (ASVS). OWASP Infrastructure analysed by security staff. There are logging DEPLOYMENT AND Implementation NEFARIOUS services that send the logs to a remote location INTEGRATION - CSA IoT Security Controls ACTIVITY / ABUSE instead of storing them locally so that, if the MAINTENANCE AND Framework. Cloud Security Alliance DAMAGE / LOSS software is compromised, the data are not DISPOSAL (CSA)

compromised.

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

- SECURE CODING BEST PRACTICES HANDBOOK. VERACODE

- Security Assurance in the SDLC for the Internet of Things - ISACA. ISACA

- ISO-IEC 27001. ISO

- NIST SP 800 53r5: Security and Privacy Controls for Federal Information Systems and Organizations. NIST

- Fundamental Practices for Secure Software Development, SAFECODE

- MITIGATING THE RISK OF SOFTWARE VULNERABILITIES BY ADOPTING A SECURE SOFTWARE DEVELOPMENT FRAMEWORK (SSDF). NIST

- Security for industrial automation and control systems. Part 4-1: Secure product development lifecycle requirements. IEC 62443- 4-1

- NIST SP 800 53r5: Security and Privacy Controls for Federal Information Systems and Organizations. NIST

- The BSA Framework for Secure Software. BSA Software Alliance

- GSMA IoT Security Assessment Checklist - Reference CLP12_5 and CLP13_6

- The BSA Framework for Secure Deploy detection systems to control the critical PERSONNEL Software. BSA Software Alliance physical environment (workplace, server rooms, OUTAGES etc.) where the SDLC infrastructure supports as PHYSICAL ATTACK - Fundamental Practices for Secure Security of SDLC TC-26. Implement physical FAILURES / REQUIREMENTS Infrastructure detection systems temperature control, fire/smoke detection, Software Development, MALFUNCTIONS alimentation loss, etc.) in order to avoid the loss of SAFECODE essential support for the SDLC such as NEFARIOUS ACTIVITY / ABUSE - NIST SP 800 53r5: Security and organisation network, external communication, Privacy Controls for Federal

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

external services as cloud, internet, surveillance, Information Systems and DAMAGE / LOSS etc. Deploy backup systems for critical points. Organizations. NIST

- ISO-IEC 27001. ISO

- Software Assurance Maturity Model

(SAMM). OWASP SAMM

- The BSA Framework for Secure

Software. BSA Software Alliance

- "CSA IoT Security Controls

Framework. Cloud Security Alliance (CSA) REQUIREMENTS Implement a procedure describing the steps to be OUTAGES - International Organization for DESIGN Standardization (ISO) ISO27001 6 taken in order to mitigate the damages that could UNINTENTIONAL be caused to the systems where data are stored DEVELOPMENT/IMP Planning" DAMAGES during the SDLC process (communication LEMENTATION (Accidental) - "Systems and software engineering systems, network equipment, servers, disks, data Security of SDLC TC-27. Define a mitigation —Software life cycle processes. repositories, computers, etc.), as well as the PHYSICAL ATTACK TESTING AND Infrastructure plan for physical damages ISO 12207" spaces where they are hosted, to prevent them ACCEPTANCE LEGAL from being compromised due to a fire, flood, - Fundamental Practices for Secure DEPLOYMENT AND electric shock, etc. It is also important to have a FAILURES / Software Development, INTEGRATION redundant system in place to provide support and MALFUNCTIONS SAFECODE prevent alterations in the SDLC process. MAINTENANCE AND DAMAGE / LOSS - BUILDING SECURITY IN DISPOSAL MATURITY MODEL (BSIMM).

BSIMM

- NIST SP 800 53r5: Security and

Privacy Controls for Federal

Information Systems and Organizations. NIST

- ISO-IEC 27001. ISO

OUTAGES Whitelist-based monitoring makes it possible to UNINTENTIONAL REQUIREMENTS - CSA IoT Security Controls strengthen the security of connections and servers DAMAGES DESIGN Framework. Cloud Security Alliance by controlling the applications. Only authorised (Accidental) DEVELOPMENT/IMP (CSA) Security of SDLC TC-28. Use whitelists for applications can be run, thus preventing the FAILURES / LEMENTATION

Infrastructure allowed applications execution of unauthorised software or malware. MALFUNCTIONS TESTING AND - NIST SP 800 53r5: Security and

NEFARIOUS ACCEPTANCE Privacy Controls for Federal Whitelists must be periodically updated in order to ACTIVITY / ABUSE DEPLOYMENT AND Information Systems and include the latest applications, software has to be INTEGRATION Organizations. NIST patched and tested to verify their functionality, etc. DAMAGE / LOSS

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

- SECURE CODING BEST MAINTENANCE AND PRACTICES HANDBOOK. DISPOSAL VERACODE

- Application Security Verification

Standard 4.0 (ASVS). OWASP

- Proactive Controls for developers

v3.0. OWASP

- ISO-IEC 27001. ISO Collect security logs to audit access to the SDLC PERSONNEL resources, such as access to information in - NIST SP 800 53r5: Security and OUTAGES REQUIREMENTS servers, files, data stored in physical rooms, etc. Privacy Controls for Federal UNINTENTIONAL DESIGN Regardless of whether the accesses are physical Information Systems and DAMAGES DEVELOPMENT/IMP or logical, they have to be analysed with security Organizations. NIST (Accidental) LEMENTATION tools (e.g. SIEM) to register the events (access to PHYSICAL ATTACK TESTING AND - CSA IoT Security Controls Security of SDLC TC-29. Audit the access to information, downloads, modifications, erasure LEGAL ACCEPTANCE Framework. Cloud Security Alliance Infrastructure the SDLC infrastructure attempts, etc.), identify users, and monitor the FAILURES / DEPLOYMENT AND (CSA) correct functioning of the process in order to MALFUNCTIONS INTEGRATION generate alarms if security is compromised. These - SECURE CODING BEST NEFARIOUS logs must be stored in a safe location and erased MAINTENANCE AND PRACTICES HANDBOOK. ACTIVITY / ABUSE once the period of time stipulated by the industry DISPOSAL VERACODE elapses (e.g. erasure of financial data after 5 DAMAGE / LOSS years). - The BSA Framework for Secure

Software. BSA Software Alliance

- "Information technology — Security

techniques — Information security management systems —

Requirements. ISO 27001"

- "Systems and software engineering Disseminate among internal and external —Software life cycle processes. PERSONNEL employees of the organisation a policy on how to ISO 12207" OUTAGES adequately identify themselves in the facilities, and TC-30. Implement an PHYSICAL ATTACK - Recommended Security Controls Security of SDLC on how to act and where to go if they detect identification protocol in LEGAL REQUIREMENTS for Federal Information Systems Infrastructure unauthorised individuals attempting to access the your facilities NEFARIOUS and Organizations. NIST 800-53 facilities of the organisation for malicious purposes ACTIVITY / ABUSE such as sabotage, industrial espionage, or the - Software Assurance Maturity Model DAMAGE / LOSS theft of confidential information. (SAMM). OWASP SAMM

- Security for industrial automation and control systems. Part 4-1:

Secure product development

lifecycle requirements. IEC 62443-

4-1

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

- The BSA Framework for Secure Software. BSA Software Alliance

- MITIGATING THE RISK OF SOFTWARE VULNERABILITIES BY ADOPTING A SECURE SOFTWARE DEVELOPMENT FRAMEWORK (SSDF). NIST

- Application Security Verification Standard 4.0 (ASVS). OWASP

- Proactive Controls for developers v3.0. OWASP

- Security Assurance in the SDLC for the Internet of Things - ISACA. ISACA Security does not end once the software is produced. During the operation it is necessary to - "Systems and software engineering enforce the end users to safely utilise the — PERSONNEL application. Therefore, mechanisms must be LEGAL - Software life cycle processes. ISO established during the SDLC process to ensure it, UNINTENTIONAL DEPLOYMENT AND 12207" namely: not allowing operation with password and Secure TC-31. Enforce the change DAMAGES INTEGRATION user by default, ensuring that passwords have a - SECURE CODING BEST Implementation of default settings (Accidental) MAINTENANCE AND minimum level of security (length, characters, etc.), PRACTICES HANDBOOK. FAILURES / DISPOSAL including functions to manage user passwords VERACODE MALFUNCTIONS (e.g. enforcing change cycles every 90 days, etc.), DAMAGE / LOSS - Fundamental Practices for Secure closing the user session after an inactivity time, locking the access out after multiple authentication Software Development, fails, enable user notifications of updates, etc. SAFECODE

- CSA IoT Security Controls Framework. Cloud Security Alliance (CSA)

- Application Security Verification Standard 4.0 (ASVS). OWASP

- Security for industrial automation and control systems. Part 4-1: Secure product development lifecycle requirements. IEC 62443- 4-1

- NIST SP 800 53r5: Security and Privacy Controls for Federal Information Systems and Organizations. NIST

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

- ISO-IEC 27001. ISO

- "Systems and software engineering —

- Software life cycle processes. ISO 12207"

- Security for industrial automation and control systems. Part 4-1: Secure product development lifecycle requirements. IEC 62443- 4-1

- MITIGATING THE RISK OF SOFTWARE VULNERABILITIES BY ADOPTING A SECURE PERSONNEL SOFTWARE DEVELOPMENT UNINTENTIONAL FRAMEWORK (SSDF). NIST DAMAGES - Proactive Controls for developers Choose well-supported underlying components OUTAGES DEVELOPMENT/IMP v3.0. OWASP that do not require customizations that may lead to LEGAL LEMENTATION Secure TC-32. Use substantiated losing security oversight and use proven tools to FAILURES / - SECURE CODING BEST Implementation underlying components TESTING AND apply security hardening practices (e.g. MALFUNCTIONS PRACTICES HANDBOOK. ACCEPTANCE metasploit). NEFARIOUS VERACODE ACTIVITY / ABUSE - Fundamental Practices for Secure DAMAGE / LOSS Software Development, SAFECODE

- Software Assurance Maturity Model (SAMM 1.5v). OWASP

- CSA IoT Security Controls Framework. Cloud Security Alliance (CSA)

- Application Security Verification Standard 4.0 (ASVS). OWASP

- The BSA Framework for Secure Software. BSA Software Alliance

- Security for industrial automation and control systems. Part 4-1:

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

Secure product development lifecycle requirements. IEC 62443- 4-1

- ISO-IEC 27001. ISO

- NIST SP 800 53r5: Security and Privacy Controls for Federal Information Systems and Organizations. NIST

- The BSA Framework for Secure Software. BSA Software Alliance

- MITIGATING THE RISK OF SOFTWARE VULNERABILITIES BY ADOPTING A SECURE SOFTWARE DEVELOPMENT FRAMEWORK (SSDF). NIST

- Application Security Verification Standard 4.0 (ASVS). OWASP

- Proactive Controls for developers v3.0. OWASP

- Security Assurance in the SDLC for Ensure that the SDLC process addresses the PERSONNEL the Internet of Things - ISACA. provision of adequate measures in order to include LEGAL different setting options for end-users upon first UNINTENTIONAL DEPLOYMENT AND ISACA TC-33. Provide secure Secure usage of an IoT solution to enable a continuous DAMAGES INTEGRATION configuration options for - Fundamental Practices for Secure Implementation improvement of security, such as, for instance, the (Accidental) MAINTENANCE AND end users Software Development, ability to disable features or functionalities that are FAILURES / DISPOSAL SAFECODE not going to be used or to add automatic security MALFUNCTIONS check mechanism. DAMAGE / LOSS - CSA IoT Security Controls Framework. Cloud Security Alliance (CSA)

- Security for industrial automation and control systems. Part 4-1: Secure product development lifecycle requirements. IEC 62443- 4-1

- NIST SP 800 53r5: Security and Privacy Controls for Federal Information Systems and Organizations. NIST

- ISO-IEC 27001. ISO

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

- Security for industrial automation and control systems. Part 4-1: Secure product development lifecycle requirements. IEC 62443- 4-1

- Software Assurance Maturity Model (SAMM 1.5v). OWASP

- MITIGATING THE RISK OF SOFTWARE VULNERABILITIES BY ADOPTING A SECURE SOFTWARE DEVELOPMENT FRAMEWORK (SSDF). NIST

- BUILDING SECURITY IN MATURITY MODEL (BSIMM). BSIMM

- The BSA Framework for Secure PERSONNEL REQUIREMENTS Software. BSA Software Alliance One of the key problems in the IoT world is the UNINTENTIONAL DESIGN lack of standardization. This fact causes that the DAMAGES DEVELOPMENT/IMP - Proactive Controls for developers interconnectivity between different devices is not OUTAGES LEMENTATION v3.0. OWASP TC-34. Implement Secure easy and autonomous, which makes their LEGAL TESTING AND interoperability open - "Systems and software engineering Implementation integration difficult. Implement technologies based FAILURES / ACCEPTANCE standards — on open standards (e.g. OCF, oneM2M, etc.) to MALFUNCTIONS DEPLOYMENT AND ensure that communication and integration NEFARIOUS INTEGRATION - Software life cycle processes. ISO between different devices is secure and reliable. ACTIVITY / ABUSE MAINTENANCE AND 12207" DAMAGE / LOSS DISPOSAL - SECURE CODING BEST PRACTICES HANDBOOK. VERACODE

- Fundamental Practices for Secure Software Development, SAFECODE

- BUILDING SECURITY IN MATURITY MODEL (BSIMM). BSIMM

- CSA IoT Security Controls Framework. Cloud Security Alliance (CSA)

- Application Security Verification Standard 4.0 (ASVS). OWASP

- NIST SP 800 53r5: Security and Privacy Controls for Federal

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

Information Systems and Organizations. NIST

- ISO-IEC 27001. ISO

By enabling devices to advertise their intended FAILURES / DESIGN - RFC 8520, Manufacturer Usage TC-35. Enable devices to and supported functionality, the threat surface can MALFUNCTIONS Secure DEVELOPMENT/IMP Description Specification advertise their access and be significantly reduced. An indicative practical NEFARIOUS Implementation LEMENTATION network functionality example involves the use of IETF RFC 8520 on ACTIVITY / ABUSE Manufacturer Usage Description Specification.

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

A ANNEX: SDLC STANDARDS AND BEST PRACTICES

The following table summarises the main standards and best practice guides used during the development of the security measures previously introduced. These standards and guides bring together the security considerations to take into account through the entire SDLC process and they are analysed in this study as a baseline for the proposed security measures.

Publisher Title Reference

ISO ISO 12207:2008 Systems and Software Engineering – Software https://www.iso.org/standard/43447.html Life Cycle Processes

(International Organization for

ISO 30141: Internet of Things - Reference Architecture https://www.iso.org/standard/65695.html

Standardization)

ISO 27001:2013: Information security management https://www.iso.org/standard/54534.html

IEC/ISA

IEC 62443-4-1: Security for Industrial automation and control

(International

systems. Electrotechnical https://webstore.iec.ch/publication/63337 Commission/Standard Part 4-1: Secure product development lifecycle requirements

for Automation)

IoT Security Guidance https://www.owasp.org/index.php/IoT_Security_Guidance#Developer_IoT_Security_Guidance

OWASP

https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standa Application Security Verification Standard (ASVS) 4.0 (Open Web Application rd_Project#tab=Downloads

Security Project)

Security Champions Playbook https://www.owasp.org/index.php/Security_Champions_Playbook

Security by Design principles https://www.owasp.org/index.php/Security_by_Design_Principles

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

Software Assurance Maturity Model (SAMM 1.5v) https://www.owasp.org/index.php/OWASP_SAMM_Project#tab=Main

CLASP Concepts https://www.owasp.org/index.php/CLASP_Concepts

Internet of Things Top 10 https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project#tab=IoT_Top_10

API Security Top 10 2019 https://www.owasp.org/index.php/OWASP_API_Security_Project

Proactive Controls for developers v3.0 https://www.owasp.org/index.php/OWASP_Proactive_Controls

OWASP Dependency Check https://www.owasp.org/index.php/OWASP_Dependency_Check

BSA

The BSA Framework for Secure Software https://ww2.bsa.org/~/media/Files/Policy/BSA_2019SoftwareSecurityFramework.pdf

(BSA Software Alliance)

CSA

IoT Security Controls Framework https://cloudsecurityalliance.org/artifacts/iot-security-controls-framework

(Cloud Security Alliance)

ETSI TS 103 645 Cyber Security for Consumer Internet of https://www.etsi.org/deliver/etsi_ts/103600_103699/103645/01.01.01_60/ts_103645v010101p.

ETSI

Things pdf

NIST NIST Cloud Computing Standards Roadmap https://www.nist.gov/publications/nist-cloud-computing-standards-roadmap

(National Institutes of Standards and Technologies)

Mitigating the Risk of Software Vulnerabilities by Adopting a https://csrc.nist.gov/publications/detail/white-paper/2019/06/11/mitigating-risk-of-software- Secure Software Development Framework vulnerabilities-with-ssdf/draft

IoT Central Security-First Design for IoT Devices https://www.iotcentral.io/blog/security-first-design-for-iot-devices

https://www.isaca.org/Journal/archives/2017/Volume-3/Documents/Security-Assurance-in-the- Security Assurance in the SDLC for the Internet of Things SDLC-for-the-Internet-of-Things_joa_Eng_0517.pdf

ISACA

https://www.isaca.org/Journal/archives/2016/volume-3/Pages/implementing-segregation-of- Implementing Segregation of Duties duties.aspx

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

DHS

https://www.dhs.gov/sites/default/files/publications/Strategic_Principles_for_Securing_the_Inter (U.S. Department of Strategic Principles for Security the Internet of Things

Homeland Security)

OMG - CSCC

(Object Management Cloud Customer Architecture for IoT https://www.omg.org/cloud/deliverables/CSCC-Cloud-Customer-Architecture-for-IoT.pdf

Group - Cloud Standards Customer Council)

IIC

https://www.iiconsortium.org/pdf/SMM_Description_and_Intended_Use_FINAL_Updated_V1.1. IoT Security Maturity Model (Industrial Internet pdf

Consortium)

USENIX

Security in the Software Development Lifecycle https://www.usenix.org/system/files/conference/soups2018/soups2018-assal.pdf

(Advanced Computing Systems Association)

ONEM2M

(Standards for M2M and Security in the Software Development Lifecycle http://onem2m.org/cache/mod_roksprocet/1fdfd821aa

the Internet of Things)

CISA

https://www.us-cert.gov/bsi/articles/knowledge/sdlc-process/secure-software-development-life- Secure Software Development Life Cycle Processes (US-CERT) cycle-processes

IEEE

(Institute of Electrical https://internetinitiative.ieee.org/images/files/resources/white_papers/internet_of_things_feb20 IoT Security Principles and Best Practices and Electronics 17.pdf

Engineers)

IBM

(International Business IBM Point of view: Internet of Things Security https://www.ibm.com/downloads/cas/7DGG9VBO

Machines)

https://www.trendmicro.com/us/iot- TRENDMICRO IoT Security Whitepaper security/content/main/document/IoT%20Security%20Whitepaper.pdf

SAFECode https://safecode.org/wp- Fundamental Practices for Secure Software Development content/uploads/2018/03/SAFECode_Fundamental_Practices_for_Secure_Software_Develop ment_March_2018.pdf

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

https://safecode.org/wp- SAFECode Comments on EU Cybersecurity Legislation content/uploads/2018/11/SAFECode_Comments_on_EU_Cybersecurity_Legislation_Oct_201 8_v2.pdf

Tactical Threat Modeling https://safecode.org/wp-content/uploads/2017/05/SAFECode_TM_Whitepaper.pdf

The Software Supply Chain Integrity Framework http://safecode.org/publication/SAFECode_Supply_Chain0709.pdf

Managing security risks inherent in the use of third-party https://safecode.org/wp-content/uploads/2017/05/SAFECode_TPC_Whitepaper.pdf components

Software Security Takes a Champion http://safecode.org/wp-content/uploads/2019/02/Security-Champions-2019-.pdf

Australian Information

Security Management Source Code Embedded (SCEM) Security https://ro.ecu.edu.au/cgi/viewcontent.cgi?article=1134&context=ism

Conference

BSIMM

(Building Security In BSIMM9 https://www.bsimm.com/content/dam/bsimm/reports/bsimm9.pdf

Maturity Model)

https://education.emc.com/content/dam/dell-emc/documents/en-us/2018KS_Gloukhovtsev- DELLEMC IoT Security: Challenges, solutions and future prospects IoT_Security_Challenges_Solutions_and_Future_Prospects.pdf

IoTAC

(IoT Acceleration

Consortium Ministry of IoT Security Guidelines http://www.iotac.jp/wp-content/uploads/2016/01/IoT-Security-Guidelines_ver.1.0.pdf

Internal Affairs and Communications)

MSRUAS - https://www.researchgate.net/publication/322138583_Analysis_of_SDLC_Models_for_Embedd Analysis of SDLC Models for Embedded Systems SASTech Journal ed_Systems

GRAMMATECH A Four-Step Guide to Security Assurance for IoT Devices http://codesonar.grammatech.com/a-four-step-guide-to-security-assurance-for-iot-devices

NCC Group

An Implementers’ Guide to Cyber-Security for Internet of Things https://www.nccgroup.trust/uk/about-us/newsroom-and-events/blogs/2014/april/security-of- (National Computing Devices and Beyond things-an-implementers-guide-to-cyber-security-for-internet-of-things-devices-and-beyond/

Centre)

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

BOSCH Holistic IoT Security https://www.bosch-si.com/iot-platform/insights/downloads/iot-security.html

https://www.ccds.or.jp/english/contents/CCDS%20Security%20Guidelines%20for%20Product Security Guidelines for Product Categories – IoT GW %20Categories%20IoT-GW_v2.0_eng.pdf

GSMA

IoT Security Guidelines and Assessment https://www.gsma.com/iot/iot-security/iot-security-guidelines/

https://www.cisco.com/c/dam/en_us/about/doing_business/trust-center/docs/cisco-secure- CISCO Secure Development Lifecycle development-lifecycle.pdf

DZONE The DZONE Guide to Application Security 2015 Edition https://dzone.com/guides/application-security-2015-edition

FCC TAC

(Federal

https://transition.fcc.gov/oet/tac/tacdocs/reports/2015/FCC-TAC-Cyber-IoT-White-Paper- Communications Technical Considerations White Paper Community- Rel1.1-2015.pdf

Technological Advisory Council)

Secure Software

Framework Secure Software https://www.securesoftwarealliance.org/FrameworkSecureSoftware_v1.pdf

Foundation

PCI Security Standards https://www.pcisecuritystandards.org/documents/PCI-Secure-Software-Standard- Payment Card Industry Software Security Framework Council v1_0.pdf?agreement=true&time=1566543843174

Security Secure Software Development Life Cycle http://www.ijetmas.com/admin/resources/project/paper/f201509231443005088.pdf

IJETMAS

Threat Modeling for Secure Embedded Software https://pdfs.semanticscholar.org/d3a8/8f79f3baf7c1f3ad75fada8ec2b71b27ca99.pdf

IPA IoT Safety/Security Design Tutorial https://www.ipa.go.jp/files/000053921.pdf

VDOO Integrating Security into the IoT SDLC https://www.vdoo.com/blog/integrating-security-into-the-iot-sdlc/

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

https://0x7df.bsidesljubljana.si/wp- ERNW Security Bsides Ljubljana IoT and SDLC content/uploads/sites/9/ERNW_Scheuring_Security_BSides_Ljubljana_IoT_and_SDLC_2015. pdf

Advanced Science and A Study of Developing Security Requirements for https://pdfs.semanticscholar.org/6aec/74231f1716bd350b1c60b2bc3168471e1c13.pdf

Technology Letters

Internet of Things

WIND RIVER Managing the IoT Lifecycle from Design through End-of-Life https://www.windriver.com/whitepapers/managing-iot-lifecycle/2434-Cloud_white_paper.pdf

DCMS-UK

(Department for Digital, https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/ Code of Practice for Consumer IoT Security Culture, Media and file/773867/Code_of_Practice_for_Consumer_IoT_Security_October_2018.pdf

Sport, UK Government)

https://www.secura.com/pathtoimg.php?id=1213&image=source_code_analysis.p Source Code Analysis df

SECURA

https://www.secura.com/pathtoimg.php?id=1199&image=security_testing___compliance_for_i Security Testing Compliance for IoT v0.5 ot_v0.5.pdf

BISEC

(International The Role of Software testing in a Security-Oriented IoT Software https://www.metropolitan.ac.rs/files/2018/01/BISEC2017-Zbornik-ilovepdf- Development Process compressed.pdf

Conference on Business Information Security)

https://conference.eurostarsoftwaretesting.com/wp- Zephyr Continuous Testing Agility 2020 content/uploads/ContinuousTestingAgility2020-1-1.pdf

https://reader.elsevier.com/reader/sd/pii/S2212827116309878?token=626E3AF21033F555197 ScienceDirect Secure IoT Devices for the Maintenance of Machine Tools 704E40AF514E48A61FEAA92C01B196F9CB9390B6B292E1C1119714454FAE438EAD6E14 434EDF5

GitHub Secure Software Development in the Financial Services Industry https://resources.github.com/downloads/GitHub_eBook_FSI_Secure_Development.pdf

https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/developing- INTEL Secure Solutions for the IoT solutions-for-iot.pdf

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

https://www.sans.org/reading-room/whitepapers/securecode/security-checklist-web- A Security Checklist for Web Application Design application-design-1389

SANS Institute

Secure Coding. Practical steps to defend your web apps. https://software-security.sans.org/resources/paper/cissp/application-security

CMU Threat Modeling: A Summary of Available Methods https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=524448

(Carnegie Mellon University)

Security Quality Requirements Engineering Technical Report https://resources.sei.cmu.edu/library/asset-view.cfm?assetID=7657

VERACODE Secure Coding Best Practices https://info.veracode.com/secure-coding-best-practices-hand-book-guide-resource.html

INDUSA 10 Challenges Every Software Product Developer Faces http://www.indusa.com/articles/10-challenges-every-software-product-developer-faces/

LANDesk Resolving the Top Three Patch Management Challenges https://www.infosecurityeurope.com/__novadocuments/20559

Proposed Embedded Security Framework for Internet of Things. https://www.researchgate.net/profile/Jaydip_Sen/publication/252013823_Proposed_Embedded IEEE _Security_Framework_for_Internet_of_Things_IoT/links/00b495278c92a797d9000000/Propos ed-Embedded-Security-Framework-for-Internet-of-Things-IoT.pdf

UL 2900 series Standard for Software Cybersecurity for UL https://standardscatalog.ul.com/standards/en/standard_2900-1_1 Network-Connectable Products

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

B ANNEX: SECURITY IN SDLC MODELS

SDLC models are conceptual frameworks that are used to detail all activities relating to software development and the interrelations between these activities. This conceptualization allows for a structured, coordinated and well-communicated software development approach among all members of the team. Different SDLC models have been proposed over the years, including Waterfall, Agile, Spiral, DevOps, DevSecOps, etc. In general, SDLC models fall under one of the following three categories: sequential, iterative or agile (this includes the agile methods). The difference lies in the transition from one SDLC phase to another. Reflecting the diversity and intricacies of the different SDLC models, security considerations are taken into account and are incorporated in different ways. There exist several possible categorizations of the SDLC phases. In the context of this study and focusing on IoT, six distinct phases are identified (further details may be found in Section 2.2), namely: 1. Requirements, (Definition and Identification). 2. Software design. 3. Development/implementation. 4. Testing and acceptance. 5. Deployment and integration. 6. Maintenance and disposal. The Waterfall SDLC model represents the 6 phases in a sequential, linear flow. Accordingly, requirements are defined at the beginning of the process. While this process might be useful for rigid and highly structured projects, it might not be very useful when considering modern development cycles that require high degrees of adaptation, extensibility and flexibility (e.g., IoT, cloud-based, etc.). Conversely, the Agile SDLC model is meant to represent a more flexible means to define and capture new requirements. For this reason, it makes use of short, time-constrained development cycles that facilitate the adaptability of the final software product or service by means of validation of the outputs of these agile cycles. The Waterfall and Agile models are the foundations for other, more recently introduced models. GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

When considering security, the Waterfall model plans for security at the beginning of the SDLC, but actual security tests are not carried out until the final phases (Development/Implementation or Integration and Testing). This implies that security is not an integral part of the development process and is addressed only when the final product is nearing completion. In the Agile model, security (and other types of) testing take place in the context of every cycle and not as a whole, similarly to the definition of security requirements. Moreover, it is normally the case that different teams are in charge of different cycles and therefore capturing of security requirements and testing might differ inbetween cycles. In the context of agile models, the most critical aspect for security is to ensure the consistency of security requirements, design setup and testing in each iteration. Building on the Waterfall model, more iterative SDLC models were proposed such as the Spiral one. Software engineers using the Spiral SDLC model collect a series of requirements at the beginning of the process, which are then checked at every stage of development. This allows the inclusion of additional requirements as necessary in every iteration or “spiral”, so that by the time the application reaches the deployment and maintenance phases it has considered additional security requirements that were not planned for in the beginning. Building on the Agile SDLC model, the DevOps model provides faster release cycles since deployment and integration are also a part of the cycle (in traditional Agile, it is only software design and development/implementation). DevOps was introduced to eliminate the barriers between development and operations, bringing together professionals from both teams and accordingly leads to integrated and more complete security tests. In addition, other well-known SDLC models based on Agile include XP (Extreme Programming), Scrum and Kanban. Of particular interest to secure SDLC is the DevSecOps SDLC model, which integrates security practices in the DevOps methodology. In this way, security is considered in all phases of software development in an agile manner. In the context of IoT software development, the particularities of this dynamic and adaptive ecosystem should be taken into account when selecting the most appropriate SDLC model. Given the diversities of the different models and the way in which security is addressed in each one of them, it is evident that the decision on which SDLC model to adopt should be given considerable thought, since it will affect the overall outcome. Figure 10 depicts different SDLC models and how they manage the different SDLC phases . GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

Figure 9: Overview of SDLC models GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

C ANNEX: IOT SDLC TESTING

Tests Description

DAST allows to study the software when it runs, by implementing a package of prebuilt attacks (less limited and more automated than a human attacker) and aiming them against the executed software. DAST can find vulnerabilities when all of the components are integrated and if the test is Dynamic Analysis Security Testing (DAST) successful, an attacker can carry out the attack. It is recommended to use DAST with SAST to obtain more complete test analysis. This kind of test can be fully automatic using security scanners and/or vulnerability scanning tools, or complemented with a manual review to check the results and perform complex tests manually.

SAST involves the use of tools and techniques to analyse all elements of software (including source code, bytecode and any used binaries). SAST Static Analysis Security Testing (SAST) tests software that is not currently executed and is thus complementary to DAST. The aim is to identify coding and design software aspects that might indicate the existence of possible known vulnerabilities.

This type of security testing aims to be an evolution of DAST testing with the knowledge of the SAST testing (information flows), where the test

Interactive Analysis Security Testing (IAST)

checks the execution flow during runtime. It is usually automated and used in DevOps scenarios.

Software dependencies are as important as the code itself, and vulnerabilities detected within them can have severe consequences. This is particularly the case with IoT software, which is commonly comprised of several third-party components and libraries. It is thus recommended as a

Software Composition Analysis (SCA)

good practice to check whether software dependencies can be trusted before deployment in a production environment. This provides more confidence in the software as a whole.

Validation acceptance testing is focused on realistic test scenarios, such as sequences of actions performed by the user (use cases). The outcomes of this type of testing yields whether the system can be securely used in real-world scenarios, Validation acceptance tests are the final Validation (Acceptance) Testing and most critical test prior to deployment and integration, because it will determine whether the software is ready to roll out to the market. This type of testing aims at assessing whether the software does what it was envisaged to do at the beginning of the project, i.e. based on the security requirements.

Fuzzing generates (or mutates) large sets of data and passes it to an application’s data parsers to check its reaction. This kind of testing technique can reveal potential security vulnerabilities and weaknesses and help to mitigate attacks such as ones based on buffer overflows and data input

Fuzzing test

validation (e.g. cross-site scripting). In the case of IoT, complexity of fuzzing increases in accordance to the large number of available protocols and data formats, so this is a particularity that needs to be catered for by the testing team.

Software verification is the process used to determine whether the outcome of a given stage of product development (i.e. software development) Security verification and validation conforms exactly to the requirements set at the beginning of the stage. Software validation is the process used to determine whether the product (computer program, operating system, appliance etc.) satisfies its intended use and user needs. Requirements, lifecycle processes and other supporting artifacts can also be validated for their conformance to the expected results. Careful consideration has to be given to IoT software,

GOOD PRACTICES FOR SECURITY OF IOT

NOVEMBER 2019

since the logic and functionality of the software depends on the context of use, therefore appropriate tests should be devised to ensure full coverage of the expected functionality.

Despite being a time-consuming activity, the manual review of code is one of the best options to detect potential security issues that might reside within the code. Automated tools can provide a solid basis of understanding, however employing experienced security experts to review the code Manual Code Review may lead to the detection of more complex security issues (e.g. logic bombs) following the information flow. A slight variation of this testing technique is peer code review, where a different member of the team checks the code developed to ensure that best practices (quality and security) have indeed been followed.

This type of testing aims to check whether the software is able to operate in high load conditions (e.g. Internet rush hour), taking into account the constraints in terms of resources, which many IoT solutions face. This might provide interesting results in terms of availability of the systems. It is

Load Testing

important to keep in mind to check for all flows in an IoT software solution and to load test all of them, including the ones referring to cloud and possible backend servers.

Stress testing test is similar to load testing, but in this case the objective is to find the point where the tested software will fail, i.e. the maximum load that it is able to manage. This kind of test reveals the potential impact on availability of the software, however in the context of IoT it should be

Stress Testing

taken with a grain of salt, since due to limited resources and the need to have lightweight solutions the results will need to be seen under this perspective.

Regression testing type is one of the most useful ones in IoT ecosystems, given that they are subject to frequent software updates to enhance their functionalities and security levels. Accordingly, regression is used to ensure that functionalities already deployed in the software or solution work Regression Testing after a modification. This way, not only new modules or functionalities are checked, but previous ones are also tested for compatibility or any other inadvertent changes in their behavior after a new type of functionality has been deployed. Regression testing is particularly common in DevOps scenarios, where software is continuously tested prior to its deployment.

Integration testing is used in software testing cases where the solution is made up of different elements. In such cases, it is necessary to check whether the different elements can work together as expected. IoT software development by definition falls under this category, since it integrates

Integration Testing

components of end devices, communications/networks, cloud-based ones, etc. Accordingly, integration testing is significant in the context of IoT since it is meant to verify that no security issues will arise when all elements of the IoT solution are integrated.

Penetration testing is by definition related to security. Such tests consist of simulated attacks on the developed software solution in order to evaluate its security solution. The level of sophistication of the testing team influences the success of penetration tests, since the more

Penetration Testing

sophisticated the attack, the more it is expected to uncover security issues. Pentesting IoT software has recently received attention with the proliferation of IoT end devices and the popularity of publicized attacks on them, as well as the publication of relevant automated tools .

IoT is inherently linked to cyber-physical deployments and this implies the need to consider safety in tandem with cybersecurity, as emphasized in 53 54 the ENISA studies on Smart Manufacturing and Industry 4.0 . Safety testing is aimed at addressing safety aspects related to the developed

Safety Testing

software solutions and examine any potential adverse effects. All elements of the software that may impact the physical aspects of the IoT system or service should be examined during these tests, as well as any interdependencies of said elements.

-N -EN -880 -19 -02 TP ABOUT ENIS A The European Union Agency for Cybersecurity (ENISA) has been working to make Europe cyber secure since 2004. ENISA works with the EU, its member states, the private sector and Europe’s citizens 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. Since 2019, it has been drawing up cybersecurity certification schemes. More information about ENISA and its work can be found at www.enisa.europa.eu. ISBN 978-92-9204-316-2 DOI: 10.2824/742784 doi: 0000.0000/000000