5.3 EVALUATION AND CERTIFICATION
A comprehensive global IoT certification framework or self-certification solution does not yet exist; it remains an open challenge to develop globally recognised and adopted cybersecurity evaluation and certification regimes for IoT devices. Given that a system of secure components is not by definition a secure ecosystem, evaluation and certification regimes should include individual components, the wider network of systems and components, and the global ecosystem. An evaluation and certification scheme should be based on a generic and common framework, possibly with businessor application-specific provisions. Such a framework may provide assurance similar to the Common Criteria for Information Technology Security Evaluation (ISO/IEC 15408). An alternative approach to certification may be to strengthen and modernise liability laws to encompass IoT products and ecosystems; this is discussed in the section on Responsible Industry Ecosystem.
5.3.1 Current Landscape and Recent Developments
Independent laboratories such as UL130, Brightsight131, and Riscure132, as well as government bodies such as US-CERT of the U.S. Department of Homeland Security, provide cybersecurity assessment and certification services and typically focus on vulnerability scanning and architecture design reviews. While they have taken early steps in IoT, they may not be ready for more comprehensive functional testing of IoT devices or for domain-specific testing; for instance, the security of a software application can be tested but not the effects that cascade from cybersecurity to functional safety. This is also because of the lack of globally-accepted IoT security standards and certification schemes to test and certify against.
Trusted IoT security labels
An IoT security label should give a baseline security requirement of protection, and the level of assurance for this needs to be defined. The label should provide a clear indication of the security achieved. AIOTI’s workshop on Security and Privacy in the Hyper-Connected World133 introduced a set of possible labels: 1) Security certified by third party 2) Managed security (maintained) 3) Secure update mechanism implemented (maintainable) 4) Access-controlled device, based on “trusted manufacturer” and self-assessment of security 5) No security. Separately, the Ministry of Economic Affairs and Climate and the Ministry of Justice and Security in the Netherlands134 have requested the industry to design a security labelling system and guidelines specifying: – Level of security, – Whether the device is automatically updated, – Lifespan of support by the manufacturer, – Device performance and functions when it is disconnected from the internet. In parallel, during the 2018 edition of the Singapore International Cyber Week (SICW)135, the Cyber Security Agency of Singapore hosted a leadership dialogue with various National Certification Bodies to exchange perspectives on a practical and balanced approach to address the evaluation of IoT devices, in consideration of the fact that this space is characterised by fast-moving innovations.
IoT Security Foundation
The IoT Security Foundation’s (IoTSF) IoT Security Compliance Framework136 aims to consistently evaluate the security of a wide range of IoT devices. To make the framework more practical across a variety of applications, IoTSF adopts a risk-based approach derived from the commonly used CIA Triad. The framework defines five Compliance Classes that achieve progressively higher levels of Confidentiality, Integrity and Availability. – Class 0: where compromise to the data generated or loss of control is likely to result in little discernible impact on an individual or organisation. – Class 1: where compromise to the data generated or loss of control is likely to result in limited impact on an individual or organisation. – Class 2: in addition to class 1, the device is designed to resist attacks on availability that would have significant impact on an individual or organisation, or impact many individuals. For example, by limiting operations of an infrastructure to which it is connected. – Class 3: in addition to class 2, the device is designed to protect sensitive data including sensitive personal data. – Class 4: in addition to class 3, where compromise to the data generated or loss of control have the potential to affect critical infrastructure or cause personal injury. For instance, a thermostat is considered to fall under Class 1 since – it does not store sensitive or personally-identifiable information. – it needs to report accurate data and external tampering with data values could result in business impact. – individual device unavailability would have little impact, but a DoS of multiple devices could result in significant business impact. Based on the Compliance Class determined for a particular product, a checklist of requirements is provided. Such a checklist could be made mandatory by procuring parties, as could a third-party audit to verify compliance with the checklist.
Common Criteria
Traditional IT products, such as firewalls and switches, are routinely subjected to Common Criteria (CC) evaluations using independent laboratories. Certificates are issued by participating national governments and recognised by signatories worldwide. The CC allows product developers to document their product’s Security Functional Requirements (SFRs) in a Security Target (ST). An independent laboratory can conduct a CC evaluation to assess the product against the SFRs. The robustness of the evaluation depends on the desired Evaluation Assurance Level (EAL). In theory, this approach allows an IoT product developer to demonstrate that their product meets specific security functional requirements. The flexible nature of CC evaluations allows each developer to choose the SFRs against which their product is evaluated, but this flexibility can make it difficult to compare similar products. For example, two firewall vendors could choose different SFRs and yet market their products as having achieved Common Criteria certification. To address this, Protection Profiles (PPs) exist for some types of common IT products. Each PP includes a set of SFRs along with specific test and assurance requirements. Products submitted for PP-based CC evaluations must exhibit exact conformance with the PP. Signatories to the CC Recognition Agreement (CCRA) recognise CC certification138 and specifically the collaborative Protection Profiles (cPPs)139. The cPP for Network Devices v2.1140 seems to be the profile to build on for IoT Security; however, it is noted that this cPP lacks IoTspecific criteria pertaining to, for example, device resource constraints and the heterogeneity of devices and network environments. Separately, the German Federal Office for Information Security (BSI)141 advocates for trustworthy products and systems in the energy network and has developed a protection profile for the gateway of a smart metering system142 that follows the rules of Common Criteria in describing the threats to a certain target that needs protection and defining the minimum requirements for appropriate safety precautions. While well established, CC certification is often said to be a slow and expensive process typically costing manufacturers six figures and taking many months143. While it appears well-suited for testing computer systems for sale to governments, it may not be as appropriate for the fastmoving and low-cost world of IoT. Non-CC alternatives can provide a light-touch approach to certification and may prove more suitable.
EU Cybersecurity Certification Framework
The European Union has identified that certification plays a critical role in increasing trust and security in products and services that are crucial for the EU Digital Single Market . At the moment, a number of different security certification schemes for ICT products exist in the EU. For example, smart meter producers currently need to undergo separate certification processes in France, the UK and Germany. Without a common framework for EU-wide valid cybersecurity certificate schemes, the EU identifies an increasing risk of fragmentation and barriers in the single market. In this context, the EU has proposed an EU Certification Framework for ICT security products. The proposed certification framework will provide EU-wide certification schemes as a comprehensive set of rules, technical requirements, standards and procedures. This will be based on agreement at EU level for the evaluation of the security properties of a specific ICT-based product or service e.g. smart cards. ENISA will work towards implementing this certification process. The resulting certificate will be recognised in all Member States, making it easier for businesses to trade across borders and for purchasers to understand the security features of the product or service. While the use of certification will be voluntary for the time being, the framework does avoid multiple certification processes in different Member States and creates an incentive to certify the quality and verify the security of the products and services in question.
5.3.2 Key Findings
– There is a distinct lack of labels to inform end users about IoT device security and risks. However, efforts to create a labelling scheme are under way in various parts of the world. It should be ensured that these schemes are aligned in order to create a level playing field for vendors.
– There are as yet no CC cPPs specifically for IoT devices. It should be determined whether these can be generic or specific to application domains.
– Non-CC alternatives can provide a light-touch approach to certification and should be explored.
Access to Innovation
Access to Capital
Access to Talent
Access to Market
Access to Knowledge
