– 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. 46 138 139 140 141 https://www.csa.gov.sg/programmes/csa-common-criteria https://www.commoncriteriaportal.org/pps/?cpp=1 https://www.commoncriteriaportal.org/files/ppfiles/CPP_ND_V2.1.pdf https://www.bsi.bund.de/EN/Home/home_node.html 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 142 https://www.commoncriteriaportal.org/files/ppfiles/pp0073b_pdf.pdf 143 Standardisation and Certification of Safety, Security and Privacy in the ‘Internet of Things’, JRC Technical Report, Leverett et al.