Defining the way forward for IoT security and certification schemes
This document aims to provide guidance on how to address cybersecurity of the Internet of Things (IoT) in the context of the adoption of future cybersecurity schemes under the Cybersecurity Act and other relevant European legislation. Our goal is to advance more effective cyber risk management across the European Digital Single Market.
We specifically recommend EU decision makers and ENISA:
- Promote competitiveness by ensuring IoT security requirements are uniform across and beyond the European Digital Single Market;
- Define any cybersecurity requirements on the basis of international standards;
- Avoid inconsistencies and overlaps between EU regulations – legal consistency must be a key goal of any European Commission initiative dealing with IoT security;
- Beyond a common baseline, adopt a differentiated approach to IoT domains; and
- Consider cybersecurity of the entire life cycle, beyond the device itself.
Table of content
Setting the scene
- The definition of the Internet of Things
- Distinguishing between IoT domains
- Legislative and standardisation landscape
Our five principles for IoT security
- A global and European approach to avoid fragmentation
- Cybersecurity requirements based on international standards
- A coherent framework for IoT cybersecurity
- Differentiated approach to IoT security per domain
- Moving beyond security of devices
Setting the scene
The definition of the Internet of Things
There is no common or widely recognised IoT definition in Europe or globally. Existing definitions can vary substantially as to scope and elements that can be included and risk being too broad for the purpose of targeting new technical and process requirements.
In light of this, DIGITALEUROPE believes that a workable scope for an IoT definition should refer to specific-purpose devices and their associated services that are connectable to network infrastructure, such as the Internet. Broader definitions could sweep in a wide array of very different products, potentially undercutting the coherence and security benefits of an IoT certification scheme.
Distinguishing between IoT domains
Albeit all IoT products hold the same common ground, we should recognise the different sector-specific application contexts – from consumer/home appliances to industry and automation, automotive, energy, etc. In fact, each sector presents specific and different features, environment of use and risks that would need to be taken into consideration when developing a certification scheme.
At the very least, the differentiation should follow a sectorial risk-based approach. In fact, among the various domains, there are substantial differences in terms of management environment and risk levels.
DIGITALEUROPE believes that considering different IoT domains would help in building better-targeted cybersecurity certification schemes and associated standards.
Legislative and standardisation landscape
In recent years there have been several initiatives worldwide covering cybersecurity or network information security in general as well as IoT security specifically. This situation poses a risk of a non-aligned and fragmented legislative framework.
In the EU, this includes the following initiatives:
- The Directive on security of network and information systems (NIS Directive), established in 2016, is the first pan-European cybersecurity legislation. This Directive, which focuses on national cybersecurity capabilities, could indirectly cover IoT used in critical infrastructures.
- In the context of the recently adopted European Cybersecurity Act, ENISA is considering the possibility of developing, amongst other schemes, a cybersecurity scheme specifically for the IoT.
- The New Legislative Framework (NLF) sets mandatory product safety requirements that are necessary to put products on the EU market (CE marking). Now that products tend to be connected, the European Commission is looking at how to include cybersecurity requirements in NLF directives and regulations. The first under consideration by the European Commission is the Radio Equipment Directive ((RED), which could include cybersecurity requirements through a delegated act on Internet-connected and wearable radio equipment. In addition, the Machinery Directive or the Low Voltage Directive are also analysed in this regard.
- Finally, Member States are also adopting their own national legislation on IoT security:
- Following the adoption of its code of practice on IoT in 2018, the UK is in the process of adopting mandatory requirements for business-to-consumer (B2C) IoT and has launched a consultation on the topic.
- Germany is also looking at its own IoT security label.
This legislative landscape exposes industry to a set of patchy and non-aligned laws, which create inconsistent and overlapping requirements and technical standards.
Standards are the most effective tool to introduce technical provisions without overly prescriptive requirements that might become outdated as technology evolves. In the area of cybersecurity certification, the role of global standards is key and should be used as a reference for any certification schemes.
A number of cybersecurity standards already exist for specific domains, such as IEC 62443 for industrial applications and ISO 21434 currently under development for the automotive sector. The ISO/IEC 27000 series, which is not linked to a sector, is also relevant for the IoT. Recently, ETSI adopted the first technical specification on Security for Consumer IoT: TS 103 645, which is currently transformed into a European standard under EN303645.
The IEC 62443-4-1 standard describing secure development lifecycle requirements is generic and relevant for the IoT – be it consumer, industrial or other IoT domains – as a common baseline. The standard describes a secure process including security requirement definition, secure design, secure implementation with hardening and coding guidelines, verification and validation procedure, defect management, patch management and product end of life.
In the US, NIST is currently consulting on a Core IoT Cybersecurity Baseline, building on NISTIR 8228, which advises federal agencies on managing IoT devices from a security and privacy perspective.
The work of standardisation bodies (ETSI, IEC/ISO, CEN-CENELEC) is essential for any future cyber requirements by law or certifications scheme under the Cybersecurity Act. We call on ENISA, the Commission and other European decision makers to first assess existing and upcoming standards in order to map the most relevant ones and use them as the basis to define any requirements for IoT cybersecurity. We also call on CEN-CENELEC and ETSI to cooperate on developing European standards and to align activities with those happening in ISO and IEC, especially in JTC1 SC27.
Our five principles for IoT security
A global and European approach to avoid fragmentation
- One of the main objectives of the Cybersecurity Act is to address the fragmentation of the European cybersecurity certification landscape. As some Member States are moving forward with their own legislation, national approaches to IoT threaten to undermine the competitive advantage of a European Digital Single Market without yielding meaningful security benefits. In fact, imposing IoT security requirements at the national level will impede the ability of companies operating across the EU to manage risk in a cohesive manner.
- Any European measure to address IoT cybersecurity, including any voluntary or mandatory label, regulation or certification, should aim to avoid multiple and diverging requirements across the EU.
- At the same time, as cybersecurity and technology know no borders, the EU should proactively engage for global alignment of IoT cybersecurity.
Cybersecurity requirements based on international standards
- Risk-based, testable, interoperable and globally aligned standards are and must remain the basis of any security requirements for IoT or future cybersecurity certification scheme.
We encourage regulators to first allow the development of appropriate standards and criteria for IoT security before enforcing or making applicable legislative measures.
When possible, cybersecurity requirements should be testable – the cost of verification can otherwise stifle market selection and innovation, hurting small and medium businesses in particular. Without clear and practicable testing specifications, cybersecurity requirements will become ambitious objectives but bear no particular effect on the IoT’s level of security.
- One technical specification dealing with consumer IoT has been published by ETSI, and similar ones are being developed by other bodies. Given this, there should be no temptation to draft specific security requirements that would deviate or add to the existing ones. ENISA should always refer to standards for cybersecurity requirements – if not existing, such standards should be developed in parallel to a scheme using an open transparent process.
- International and global standards must be the preference for European certification schemes, cybersecurity or cyber hygiene being a global and not a purely European issue. Similarly, for domain-specific applications, existing IEC/ISO/ETSI standards should be used for any certification schemes wherever possible.
- In view of quickly changing cybersecurity threat scenarios, standardisation of processes or management systems has increasing relevance compared to requirements of mere product properties. Relying on a secure development lifecycle process is key to reducing risk and improving trust by making products inherently more secure and better protecting both products and sensitive information. International standards (as ISO or IEC) are defining these secure practices.
A coherent framework for IoT cybersecurity
- As mentioned, some aspects of cybersecurity have been considered under individual product regulations under the NLF, while the Cybersecurity Act has entered into force and new schemes will soon be developed by ENISA. In such a situation, we see a clear risk of overlaps and inconsistencies among European legislations.
This would produce legal uncertainty, with significant impact in case of concurrent mandatory requirements and certification schemes. This would threaten European companies’ ability to compete across the Digital Single Market as well as globally, forcing them to misallocate scarce resources.
- Legal consistency must be a key goal of any new European Commission initiative dealing with IoT security. This requires careful analysis of the objectives of the existing frameworks before any new or revised instruments are put forward.
- Certification schemes developed under the Cybersecurity Act should stay voluntary and be sufficient to address the current policy goals on IoT security.
- Were cybersecurity requirements nevertheless to be introduced under the NLF, they should only address minimum essential requirements (mostly safety related) common to vertical directives and aligned with international cybersecurity standards that should be available before the entry of force of the legislation.
Having the same essential requirements would mitigate the risk of different if not contradicting measures for products that fall under more than one directive.
- As regards the RED, it is essential to avoid addressing cybersecurity requirements in a delegated act. A delegated act would be limited by its own structure to cover only a subset of provisions. Consequently, it would not be possible to ensure the necessary consistency with other existing or upcoming legislative requirements.
Differentiated approach to IoT security per domain
- A sectorial distinction should be made in the cybersecurity requirements. The recently adopted ETSI technical specification has recognised this need for a differentiated approach, with a technical specification dedicated to consumer IoT.
- Common cybersecurity requirements that are aligned with international standards could fit sector-specific IoT. However, beyond a common baseline, a segmentation between the consumer IoT and other IoT sectors or domains is required.
- Cybersecurity requirements should always be based on a risk-based approach and according to the intended use. The higher the risk, the more stringent the requirements.
Moving beyond the security of devices
- Cybersecurity should also take into account the life cycle of the device, not just product requirements – a balance needs to be sought between process, system and product security.
- A secure development lifecycle (SDL) process has the purpose of developing and maintaining secure products to make them more resilient:
- SDL allows a comprehensive approach from a product’s development throughout its lifecycle with incident and vulnerability management.
- Well-recognised international and European standards on SDL already exist, e.g. for secure development lifecycle IEC 62443 4-1 and/or ISO/IEC 27034 or vulnerability disclosure and handling (ISO/IEC 29147 and 30111).
- By introducing standardised security and compliance considerations throughout all phases of the development process, developers can help reduce the likelihood of vulnerabilities in products and services and avoid repeating the same security mistakes. Security updates should also be considered in a holistic approach.
- In addition, the manufacturer can add specific technical cybersecurity requirements based on existing standards.
- It is also crucial to look at the security of the system itself, where security of the product is only part of the security journey. By considering the system view, it is possible to go beyond device design by managing compensating controls (secure process at the commission phase, complementary secure tool and services, etc.). The role of the network is also crucial here – devices, networks and systems need to work in tandem:
- Specifically, there are things that manufacturers can develop into the device or achieve through services or processes, which enable the network to more effectively handle security at scale.
- The network has the added advantage of being well-placed to secure IoT devices with no or limited embedded security capabilities as a result of design limitations, such as processing capabilities or battery life, or due to manufacturers’ inexperience or unwillingness to do so, often due to cost considerations. This includes the vast number of legacy devices that are already on the market.