DCMS, Code of Practice Mapping (Department for Digital, Culture, Media & Sport)
# Req Id Main Cat Organisation Standard Recommendation Name Recomm Number Section Recommendation Extracted From Source Notes Added At Version
1 1052 Make systems resilient to outages W3C Web of Things (WoT) Security and Privacy Considerations 4.1.3 Avoid Heavy Functional Processing without Authentication. When defining WoT Interfaces exposed by a TD, it is important to avoid any heavy functional processing before the successful authentication of a WoT client. Any publicly exposed network interface should avoid heavy processing altogether. 1 View
2 1051 Make systems resilient to outages US National Institute of Standards and Technology (NIST) NIST SP.800-160 Systems Security Engineering F.2.6 Secure Failure and Recovery. The principle of secure failure and recovery states that neither a failure in a system function or mechanism nor any recovery action in response to failure should lead to a violation of security policy. This principle parallels the principle of continuous protection to ensure that a system is capable of detecting (within limits) actual and impending failure at any stage of its operation (i.e., initialization, normal operation, shutdown, and maintenance) and to take appropriate steps to ensure that security policies are not violated. 1 View
3 1050 Make systems resilient to outages UL IoT Security Top 20 Design Principles 1 Provide a manual override for any safety-critical operations Advanced features are great when they work. However, sometimes these features fail – often through no fault of the system itself. The local network of the customer can be poorly configured, or their internet connection may become interrupted. In such cases it is important that any lack of functionality this causes does not result in a safety problem for the end user. Examples may be providing a physical key back-up for a smart door lock or a manual override and safety-limiting feature on an IoT thermostat. 3 View
4 1049 Make systems resilient to outages U.S. Department of Homeland Security Strategic Principles for Securing The Internet of Things (IoT) Design with system and operational disruption in mind. Understanding what consequences could flow from the failure of a device will enable developers, manufacturers, and service providers to make more informed risk-based security decisions. Where feasible, developers should build IoT devices to fail safely and securely, so that the failure does not lead to greater systemic disruption. Incorporate Security at the Design Phase 1 View
5 1048 Make systems resilient to outages Open Web Application Security Project (OWASP) IoT Security Guidance I3: Insecure Network Services Review all required network services for vulnerabilities such as buffer overflows or denial of service 1 View
6 1047 Make systems resilient to outages Object Management Group (OMG) Cloud Standards Customer Council (CSCC) Cloud Customer Architecture for IoT Resilience In IoT systems resilience and fault tolerance is very important. IoT systems should not depend on one single component at any point and should tolerate the failure of a single component, such as a single IoT device. Components in the provider cloud can be made resilient through the use of multiple instances of programs and cloud services allied with data replication and redundancy on multiple storage systems. The networks should also be resilient, for example with multiple paths and multiple providers in the public network. 1 View
7 1046 Make systems resilient to outages IoT Security Initiative CyberSecurity Principles of IoT PRINCIPLE 18 Devices supporting sensitive or safety-critical functions are designed and architected to continue safe and secure operation during communications interruption or failure. 1 View
8 1045 Make systems resilient to outages IoT Security Foundation IoT Security Compliance Framework 2.0 2.4.13.21 Where a Product or Service includes any safety critical or life-impacting functionality, the services infrastructure shall incorporate redundancy to ensure service continuity and availability. 3 View
9 1044 Make systems resilient to outages IoT Security Foundation IoT Security Compliance Framework 2.0 2.4.7.24 As far as reasonably possible, devices should remain operating and locally functional in the case of a loss of network connection and should recover cleanly in the case of restoration of a loss of power. Devices should be able to return to a network in a sensible state and in an orderly fashion, rather than in a massive scale reconnect. 3 View
10 1043 Make systems resilient to outages Internet Research Task Force (IRTF) Thing-to-Thing Research Group (T2TRG) State-of-the-Art and Challenges for the Internet of Things Security 5.1.2 The tight memory and processing constraints of things naturally alleviate resource exhaustion attacks. 1 View
11 1042 Make systems resilient to outages Internet Engineering Task Force (IETF) Best Current Practices (BCP) for IoT Devices 2.2.3 A device SHOULD be designed to gracefully tolerate excessive numbers of authentication attempts, for instance by giving CPU priority to existing protocol sessions that have already successfully authenticated, limiting the number of concurrent new sessions in the process of authenticating, and randomly discarding attempts to establish new sessions beyond that limit. The specific mechanism is a design choice to be made in light of the specific function of the device and the protocols used by the device. What's important for this requirement is that this be an explicit choice. Resistance to authentication DoS attacks 1 View
12 1041 Make systems resilient to outages International Electrotechnical Commission (IEC) IoT 2020: Smart and secure IoT platform 5.2.5.4 Reliable and trustworthy actuation requires new technologies and extended system architectures to ensure reliable execution of tasks and to be able to recover from system failures, e.g. from the network or from devices. 1 View
13 1040 Make systems resilient to outages Industrial Internet Consortium (IIC) Industrial Internet of ThingsVolume G4: Security Framework v1.0 8.1 SECURITY THREATS AND VULNERABILITIES ON ENDPOINTS. Breach of the Monitoring & Analysis system, ⑫: An attacker could gain visibility on the functions of the monitored system. For example, an attacker could modify monitoring data to make it appear as if a particular event did not occur. Modification of the security logs and monitoring data may result in undetected vulnerabilities or compromised states. As a result, attackers would benefit from a coverage gap, compromising endpoint hardware and software or destroying evidence of their activities after an attack. 1 View
14 1039 Make systems resilient to outages Industrial Internet Consortium (IIC) Industrial Internet of ThingsVolume G4: Security Framework v1.0 8.1 SECURITY THREATS AND VULNERABILITIES ON ENDPOINTS. Unwanted changes to Endpoint Data, ⑪: Data throughout the endpoint from low-level firmware all the way up the software stack represents a key area of vulnerability. These vulnerabilities include unauthorized access to mission-critical or private data. Attackers may adversely affect the behavior of the system by injecting false data. Denial-of-service attacks on data access may impede timely and accurate execution of the endpoint functionality resulting in costly outcomes. 1 View
15 1038 Make systems resilient to outages GSMA IoT Security Guidelines Endpoint Ecosystem CLP13_5.8.3 Restrict communications options to the strict minimum required for a given IoT Service. 1 View
16 1037 Make systems resilient to outages GSMA IoT Security Guidelines Endpoint Ecosystem CLP13_5.8.3 Protection against Denial of Service attacks 1 View
17 1036 Make systems resilient to outages GSMA IoT Security Guidelines Endpoint Ecosystem CLP13_5.8.3 Backup channels in case of physical or logical link failure 1 View
18 1035 Make systems resilient to outages GSMA IoT Security Guidelines Endpoint Ecosystem CLP13_8.8 Endpoints that provide critical services to the user must be enabled with a warning threshold that indicates power-related events. These events may include:  Low battery state Critically low battery state Black-out events Brown-out events Switch to battery back-up events Medium priority recommendation by GSMA 1 View
19 1034 Make systems resilient to outages GSMA IoT Security Guidelines Endpoint Ecosystem CLP13_8.7 Components within an embedded system are designed to be used within certain environmental thresholds. This includes voltage levels, current draw, ambient or operating temperature, and humidity. Each component is typically rated for certain windows of approved levels. If the device is subjected to states above or below a given window, the component may act erratically, or behave in a fashion that is useful to an adversary.Therefore, it is important to detect changes to these environmental levels to determine whether the device should continue running, or if it should power off. It should be noted, however, that powering off may be a desired effect, and that the adversary may abuse this engineering decision to leverage a denial of service. The engineering team should evaluate this model to determine if it is more beneficial to shut down or more beneficial to attempt to stay online Medium priority recommendation by GSMA 1 View
20 1033 Make systems resilient to outages GSMA IoT Security Guidelines Endpoint Ecosystem CLP13_9.1 Intentional or Unintentional Denial of Service Mapping done by GSMA 1 View
21 1032 Make systems resilient to outages GSMA IoT Security Guidelines Endpoint Ecosystem CLP13_9.1 For radio communications, there is a constant threat of jamming, or the intentional broadcasting of noise or patterns that can be used to scramble legitimate signals. As radio signals are simply composed of electrons flying through space in a specific pattern, it is fairly easy to concoct a series of signals that interrupt or mangle the pattern that forms communications data. Low priority recommendation by GSMA 1 View
22 1031 Make systems resilient to outages GSMA IoT Security Guidelines for Service Ecosystems CLP12_5.4 For publicly accessible services, several pieces of security and reliability technology are required to maintain the availability, confidentiality, and integrity of the service:DDoS-resistant infrastructure Load-Balancing infrastructure Redundancy systems Web Application Firewalls (optional) Traditional Firewalls Critical recommendation by GSMA 1 View
23 1030 Make systems resilient to outages European Union Agency for Network and Information Security (ENISA) Baseline Security Recommendations for IoT GP-PS-04 Designing for power conservation should not compromise security. 1 View
24 1029 Make systems resilient to outages European Union Agency for Network and Information Security (ENISA) Baseline Security Recommendations for IoT GP-PS-03 Security must consider the risk to human safety 1 View
25 1028 Make systems resilient to outages European Union Agency for Network and Information Security (ENISA) Security and Resilience of Smart Home Environments 6.1 Hardware must provide basic reliability measures to resist outages and jammingThe typical examples are: • In case of outage (power, network or simply the associated cloud services): o Provide the user with a notification o Provide smart fail-safe mechanism or standalone option (if an outage or denial of service happens, devices should be able to go offline, continue to provide their functionalities, and synchronize to remote services as soon as they become available again). • For network: use the diversity of available interfaces (including hardwired connections) or RF spectrum to maintain connection. • For power: use battery back-up and/or alternate charging options. Minimum reliability 1 View
26 1027 Make systems resilient to outages European Union Agency for Network and Information Security (ENISA) Baseline Security Recommendations for IoT GP-TM-15 Design with system and operational disruption in mind. Build IoT devices to fail safely and securely, so that the failure does not lead to a greater systemic disruption. Have a fail-safe design that specifically ensures that no malfunction can impact the delivery of a commodity (e.g. energy, gas, heat or water), preventing the system from causing unacceptable risk of injury or physical damage, protecting the environment against harm, and avoiding interruption of safety-critical processes. Annex A: Detailed Security measures / Good practices 1 View
27 1026 Make systems resilient to outages European Union Agency for Network and Information Security (ENISA) Baseline Security Recommendations for IoT GP-TM-51 Implement a DDoS-resistant and Load-Balancinginfrastructure to protect the services against DDoS attacks which canaffect the device itself or other devices and/or users on the localnetwork or other networks. Annex A: Detailed Security measures / Good practices 1 View
28 1025 Make systems resilient to outages European Union Agency for Network and Information Security (ENISA) Baseline Security Recommendations for IoT GP-TM-46 Rate limiting – controlling the traffic sent or received bya network to reduce the risk of automated attacks. Annex A: Detailed Security measures / Good practices 1 View
29 1024 Make systems resilient to outages European Telecommunications Standards Institute (ETSI) Cyber Security for Consumer Internet of Things Provision 4.9-3 Devices should be able to return to a network in an expected, operational and stable state and in an orderly fashion, rather than in a massive-scale reconnect. 2 View
30 1023 Make systems resilient to outages European Telecommunications Standards Institute (ETSI) Cyber Security for Consumer Internet of Things Provision 4.9-2 As far as reasonably possible, IoT services should remain operating and locally functional in the case of a loss of network and should recover cleanly in the case of restoration of a loss of power. 2 View
31 1022 Make systems resilient to outages European Telecommunications Standards Institute (ETSI) Cyber Security for Consumer Internet of Things Provision 4.9-1 Resilience should be built in to IoT devices and services where required by their usage or by other relying systems, taking into account the possibility of outages of data networks and power. The aim of provisions 4.9-1 and 4.9-2 is to ensure that IoT services are kept up and running as the adoption of IoT devices across all aspects of a consumer's life increases, including in functions that are relevant to personal safety. The impact on people's lives could be prevalent if, for example, an internet connection is lost to a connected door and someone is locked outside. Another example is a home heating system that turns off because of a DDoS attack against a cloud service. It is important to note that other safety-related regulations can apply, but the key is to avoid making outages the cause of these problems and to design products and services ready for these challenges. 2 View
32 1021 Make systems resilient to outages European Telecommunications Standards Institute (ETSI) Cyber Security for Consumer Internet of Things 4.9 Make systems resilient to outages 2 View
33 1020 Make systems resilient to outages CableLabs A Vision for Secure IoT Prevention of IP Address Spoofing Source Address Validation (SAV) is a recommended best practice for all ISPs, hosting providers, cloud providers and others to prevent reflective DDoS attacks.[ SAV with spoofed packet dropping is supported in Cable Modem Termination Systems (CMTS) equipment deployed in cable access networks globally. This feature became available in the Data Over Cable Service Interface Specification (DOCSIS) release 3.0, first issued in 2006, as a mandatory requirement. Moreover, the DOCSIS specification requires that SAV be turned on by default for DOCSIS 3.0 and 3.1 compliant CMTS devices. 1 View
34 1019 Make systems resilient to outages CableLabs A Vision for Secure IoT Availability A secure IoT device is available when it is needed for its legitimate use and unavailable when it is not. IoT devices should be designed to function in a predictable and expected manner, if and when there is a loss of broadband connectivity or a loss of communications with any associated cloud service. Conversely, devices should use restrictive, rather than permissive, default network traffic policies to limit communications to expected norms, guarding against both unintended as well as malicious denial of service attacks that can disrupt the availability of the device or other devices on the network. 1 View
35 1018 Make systems resilient to outages CableLabs A Vision for Secure IoT DDoS Monitoring and Mitigation Systems Many cable operators have deployed DDoS monitoring and mitigation systems to ensure the continued availability of their broadband Internet access services during an attack. A DDoS attack seeks to make a device, service, or network resource unavailable to its intended users by flooding the target with superfluous network traffic in an attempt to overload systems and prevent legitimate traffic from getting through to the target of the attack. A significant DDoS attack will typically originate from many thousands or hundreds of thousands of compromised devices. Both the frequency and magnitude of DDoS attacks continue to grow, fueled in large part by the proliferation of insecure IoT. 1 View
36 1017 Make systems resilient to outages Broadband Internet Technical Advisory Group (BITAG) Internet of Things (IoT) Security and Privacy Recommendations 7.1 The IoT Supply Chain Should Play Their Part In Addressing IoT Security and Privacy Issues. Manufacturers should support for an IoT device throughout the course of its lifespan, from design to the time when a device is retired, including transparency about the timespan over which they plan to provide continued support for a device, and what the consumer should expect from the device’s function at the end of thedevice’s lifespan. 1 View
37 1016 Make systems resilient to outages Broadband Internet Technical Advisory Group (BITAG) Internet of Things (IoT) Security and Privacy Recommendations 7.5 IoT Devices Should Continue to Function If the Cloud Back-End Fails. Many services that depend on or use a cloud back-end can continue to function, even if in a degraded or partially-functional state, when connectivity to the cloud back-end is interrupted or the service itself fails. For example, a thermostat whose setting can be altered via a cloud service should in the worst case continue to operate using either lastknown or default settings. A cloud-hosted home security camera should be accessible from within the home, even when Internet connectivity fails. 1 View
38 1015 Make systems resilient to outages Broadband Internet Technical Advisory Group (BITAG) Internet of Things (IoT) Security and Privacy Recommendations 7.4 IoT Devices Should Continue to Function if Internet Connectivity is Disrupted. BITAG recommends that an IoT device should be able to perform its primary function or functions (for example, a light switch or a thermostat should continue to function with manual controls), even if it is not connected to the Internet. This is because Internet connectivity may be disrupted due to causes ranging from accidental misconfiguration or intentional attack (e.g., a denial of service attack); device function should be robust in the face of these types of connectivity disruptions. IoT devices that have implications for user safety should continue to function under disconnected operation to protect the safety of consumers. In these cases, the device or backend system should notify the user about the failure.When possible, device manufacturers should make it easy for users to disable or block (e.g.,with a firewall) various network traffic without hampering the device’s primary function. 1 View
39 1014 Make systems resilient to outages Atlantic Council Scowcroft Center for Strategy and Security Smart Homes and the Internet of Things Standalone Operation. Document which specific features and benefits will continue to work without Internet access and chronicle negative impacts from compromised devices or cloud-based systems. The most proactive companies may find it less expensive to buy back obsolete devices, rather than continue to support them." 1 View
40 1013 Ensure that personal data is protected US National Institute of Standards and Technology (NIST) NIST SP.800-160 Systems Security Engineering F.2.10 Acceptable Security. The principle of acceptable security requires that the level of privacy and performance the system provides should be consistent with the users’ expectations. The perception of personal privacy may affect user behavior, morale, and effectiveness. Based on the organizational privacy policy and the system design, users should be able to restrict their actions to protect their privacy. When systems fail to provide intuitive interfaces, or meet privacy and performance expectations, users may either choose to completely avoid the system or use it in ways that may be inefficient or even insecure. 1 View
41 1012 Ensure that personal data is protected UL IoT Security Top 20 Design Principles 9 Detail all customer data – including audio, video and personal details – that can be exported to cloud systems or third parties. Provide an opt-in for such collection Many systems provide advanced features for processing in a cloud environment. However, not all consumers are aware of the collection and export of this data, and privacy concerns may exceed the customer desire for provided features. It is important that consumers are given control of the data they provide outside their own networks through clear disclosure and an opt-in rather than a default-on process. 3 View
42 1011 Ensure that personal data is protected Telecommunications Industry Association (TIA) Realizing the Potential of the Internet of Things: Recommendations to Policy Makers Industry believes that IoT services must adopt principles similar to those that have worked successfully on the Internet to enable informed consumer choice: transparency about what data will be collected, how it will be used, and who will have access. Recommendation: Ensure Flexibility and Feasibility in Addressing Data Privacy - Page 10 1 View
43 1010 Ensure that personal data is protected Software and Information Industry Association (SIIA) Empowering the Internet of Things: Benefits 2 Privacy Rights for the IoT Should Be Based on Risk and Societal Benefits. To maximize the opportunities presented by the IoT, policies should continue encouraging transparency and control where feasible and applying an accountability framework where there is a greater emphasis on data users to exhibit responsible data stewardship and accountability. 1 View
44 1009 Ensure that personal data is protected Open Web Application Security Project (OWASP) IoT Security Guidance I5: Privacy Concerns Ensuring end-users are given a choice for data collected beyond what is needed for proper operation of the device 1 View
45 1008 Ensure that personal data is protected Open Web Application Security Project (OWASP) IoT Security Guidance I5: Privacy Concerns Ensuring a data retention policy is in place 1 View
46 1007 Ensure that personal data is protected Open Web Application Security Project (OWASP) IoT Security Guidance I5: Privacy Concerns Ensuring data is de-identified or anonymized 1 View
47 1006 Ensure that personal data is protected Open Web Application Security Project (OWASP) IoT Security Guidance I5: Privacy Concerns Ensure only authorized individuals have access to collected personal information 1 View
48 1005 Ensure that personal data is protected Open Web Application Security Project (OWASP) IoT Security Guidance I5: Privacy Concerns Ensure all collected personal data is properly protected using encryption at rest and in transit 1 View
49 1004 Ensure that personal data is protected Open Web Application Security Project (OWASP) IoT Security Guidance I5: Privacy Concerns Ensure only the minimal amount of personal information is collected from consumers 1 View
50 1003 Ensure that personal data is protected Online Trust Alliance (OTA) IoT Security & Privacy Trust Framework v2.5 31 Publicly post the history of material privacy notice changes for a minimum of two years. Best practices include date stamping, redlines, and summary of the impacts of the changes. Required (Must) 1 View
51 1002 Ensure that personal data is protected Online Trust Alliance (OTA) IoT Security & Privacy Trust Framework v2.5 30 Comply with applicable regulations, including but not limited to the Children’s Online Privacy Protection Act (COPPA) and international privacy, security and data transfer regulatory requirements. 3 4 Required (Must) 1 View
52 1001 Ensure that personal data is protected Online Trust Alliance (OTA) IoT Security & Privacy Trust Framework v2.5 29 Whenever the opportunity is presented to decline or opt out of any policy, the consequences must be clearly and objectively explained, including any impact to product features or functionality. It is recommended the end-user value of opting in and/or sharing data be communicated to the end user. Required (Must) 1 View
53 1000 Ensure that personal data is protected Online Trust Alliance (OTA) IoT Security & Privacy Trust Framework v2.5 27 Commit to not sell or transfer any identifiable consumer data unless it is a dependent part of the sale or liquidation of the core business which originally collected the data, provided the acquiring party’s privacy policy does not materially change the terms. Otherwise notice and consent must be obtained. Required (Must) 1 View
54 999 Ensure that personal data is protected Online Trust Alliance (OTA) IoT Security & Privacy Trust Framework v2.5 26 Provide controls and/or documentation enabling the consumer to review and edit privacy preferences of the IoT device including the ability to reset to the “factory default.” Required (must) 1 View
55 998 Ensure that personal data is protected Online Trust Alliance (OTA) IoT Security & Privacy Trust Framework v2.5 25 Only share consumers’ personal data with third parties with consumers’ affirmative consent, unless required and limited for the use of product features or service operation. Require that third-party service providers are held to the same polices, including holding such data in confidence and notification requirements of any data loss/breach incident and/or unauthorized access. Required (Must) 1 View
56 997 Ensure that personal data is protected Online Trust Alliance (OTA) IoT Security & Privacy Trust Framework v2.5 22 . Disclose the data retention policy and storage duration of personally identifiable information. Required (Must) 1 View
57 996 Ensure that personal data is protected Online Trust Alliance (OTA) IoT Security & Privacy Trust Framework v2.5 20 Conspicuously disclose what personally identifiable and sensitive data types and attributes are collected and how they are used, limiting collection to data which is reasonably useful for the functionality and purpose for which it is being collected. Disclose and provide consumer opt-in for any other purposes. Required (Must) 1 View
58 995 Ensure that personal data is protected oneM2M TR-0008-V2.0.1 Security (Technical Report) 9.3 Although a user of a M2M System is generally considered to be an application or functional agent that represents a human, there are links between a device and its user that can be either directly derived or indirectly deduced. Consequently, identifiers used for communication in the M2M System should not be directly related to the real identity of either the device or its user, except where this is a requirement for operation of a specific M2M Application. The use of pseudonyms is a means to support this requirement. Privacy related requirements 1 View
59 994 Ensure that personal data is protected Object Management Group (OMG) Cloud Standards Customer Council (CSCC) Cloud Customer Architecture for IoT Data Sovereignty The physical location in which data is stored may be regulated, with the regulations varying from country to country. This is particularly the case for personally identifiable information (PII) and for sensitive data such as health data and financial records. The European Union has particularly stringent regulations that apply to the PII of European citizens. As a result, any IoT cloud system must take into account data sovereignty rules and store and process data only in those locations permitted by the regulations – this requires that the provider cloud used provides the cloud service customer with control over storage and processing locations. 1 View
60 993 Ensure that personal data is protected Mozilla Minimum Security Standards for Tackling IoT Security 5. Privacy Practices The product must have a privacy policy that is easily accessible, written in language that is easily understood and appropriate for the person using the device or service. Users should at minimum be notified about substantive changes to the policy. If data is being collected, transmitted or shared for marketing purposes, that should be clear to users and, as in line with GDPR, there should be a way to opt-out of such practices. Users should also have a way to delete their data and account. Also in line with the EU’s General Data Protection Regulation (GDPR), this should include a policy setting standard retention periods wherever possible. 3 View
61 992 Ensure that personal data is protected Korea Internet & Security Agency (KISA) IoT Security Certification Service (IoT-SAP) DP5-1 De-identification must be applied to personal information processed in a device. 3 View
62 991 Ensure that personal data is protected IoT Security Initiative CyberSecurity Principles of IoT PRINCIPLE 22 A published Device Security Level Agreement (DSLA) is maintained once initially created to provide the change history of material modifications to this public information. 1 View
63 990 Ensure that personal data is protected IoT Security Initiative CyberSecurity Principles of IoT PRINCIPLE 21 A device in active use to identify and/or track persons and their activity is overtly identified as such to the public in the devices operating environment. 1 View
64 989 Ensure that personal data is protected IoT Security Initiative CyberSecurity Principles of IoT PRINCIPLE 20 A device clearly identifies the collection or processing of personally identifiable data in the Device Support-Level Agreement (DSLA). 1 View
65 988 Ensure that personal data is protected IoT Security Initiative CyberSecurity Principles of IoT PRINCIPLE 19 A device is designed and architected to protect personal privacy through data collection transparency and anonymization of user activity. 1 View
66 987 Ensure that personal data is protected IoT Security Foundation IoT Security Compliance Framework 2.0 2.4.16.6 The device manufacturer ensures that the identity of the device is independent of the end user, to ensure anonymity and comply with relevant local data privacy laws e.g. GDPR [ref 14] in the EU. 3 View
67 986 Ensure that personal data is protected IoT Security Foundation IoT Security Compliance Framework 2.0 2.4.12.15 The supplier or manufacturer performs a privacy impact assessment (PIA) to identify Personally Identifiable Information (PII) and design approaches for safeguarding user privacy [ref 49] 3 View
68 985 Ensure that personal data is protected IoT Security Foundation IoT Security Compliance Framework 2.0 2.4.12.14 The product or service only records audio/visual data in accordance with the authorization of the user (e.g., no passive recording without explicit authorisation). 3 View
69 984 Ensure that personal data is protected IoT Security Foundation IoT Security Compliance Framework 2.0 2.4.12.9 The supplier or manufacturer of any device shall provide information about how the device(s) functions within the end user’s network may affect their privacy. 3 View
70 983 Ensure that personal data is protected IoT Security Foundation IoT Security Compliance Framework 2.0 2.4.12.8 The product / service can be made compliant with the local and/or regional Personal Information protection legislation where the product is to be sold for example GDPR [ref 14]. 3 View
71 982 Ensure that personal data is protected IoT Security Foundation IoT Security Compliance Framework 2.0 2.4.12.7 There is a method or methods for the product owner to check/verify what Personal Information is collected and deleted. 3 View
72 981 Ensure that personal data is protected IoT Security Foundation IoT Security Compliance Framework 2.0 2.4.12.6 There is a method or methods for the product owner to be informed about what Personal Information is collected, why, where it will be stored. 3 View
73 980 Ensure that personal data is protected IoT Security Foundation IoT Security Compliance Framework 2.0 2.4.12.5 The Product Manufacturer or Service Provider shall ensure that a data retention policy is in place and documented for users. 3 View
74 979 Ensure that personal data is protected IoT Security Foundation IoT Security Compliance Framework 2.0 2.4.12.4 The product/service ensures that Personal Information is anonymised whenever possible and in particular in any reporting. 3 View
75 978 Ensure that personal data is protected IoT Security Foundation IoT Security Compliance Framework 2.0 2.4.12.3 The product/service ensures that only authorised personnel have access to personal data of users. 3 View
76 977 Ensure that personal data is protected IoT Security Foundation IoT Security Compliance Framework 2.0 2.4.12.2 The product/service ensures that all Personal Information is encrypted (both when stored and if communicated out of the device, see IoTSF guidance [ref 44] Part H on Network Connections 3 View
77 976 Ensure that personal data is protected IoT Security Foundation IoT Security Compliance Framework 2.0 2.4.12.1 The product/service stores the minimum amount of Personal Information from users required for the operation of the service. 3 View
78 975 Ensure that personal data is protected IoT Security Foundation IoT Security Compliance Framework 2.0 2.4.12.1 The product/service stores the minimum amount of Personal Information from users required for the operation of the service. 3 View
79 974 Ensure that personal data is protected Internet Society (ISOC) The Internet of Things: An Internet Society Public Policy Briefing Privacy IoT devices that collect data about people in one jurisdiction may transmit that data to another jurisdiction for data storage or processing. Challenges can arise if the data collected is deemed to be personal or sensitive and is subject to data protection laws in multiple jurisdictions.Enabling cross-border data flows that protect privacy and promote legal certainty for users and IoT service providers will be key for promoting the global growth of IoT 1 View
80 973 Ensure that personal data is protected Internet Society (ISOC) The Internet of Things: An Internet Society Public Policy Briefing Encourage responsible design practices for IoT services Security-by-design and privacy-by-design practices for IoT devices should be encouraged. Whether via privacy and data protection regulation, voluntary industry selfregulation, or other incentives or policy means, IoT device developers should be encouraged to respect the end-user’s privacy and data security interests and consider those interests a core element of the product-development process. 1 View
81 972 Ensure that personal data is protected Internet Research Task Force (IRTF) Thing-to-Thing Research Group (T2TRG) State-of-the-Art and Challenges for the Internet of Things Security 5.9 1. Identification - refers to the identification of the users, their IoT devices, and generated data.2. Localization - relates to the capability of locating a user and even tracking them, e.g., by tracking MAC addresses in Wi-Fi or Bluetooth.3. Profiling - is about creating a profile of the user and their preferences.4. Interaction - occurs when a user has been profiled and a given interaction is preferred, presenting (for example, visually) some information that discloses private information.5. Lifecycle transitions - take place when devices are, for example, sold without properly removing private data.6. Inventory attacks - happen if specific information about IoT devices in possession of a user is disclosed.7. Linkage - is about when information of two of more IoT systems (or other data sets) is combined so that a broader view of the personal data captured can be created.When IoT systems are deployed, the above issues should be considered to ensure that private data remains private. These issues are particularly challenging in environments in which multiple users with different privacy preferences interact with the same IoT devices. For example, an IoT device controlled by user A (low privacy settings) might leak private information about another user B (high privacy settings). How to deal with these threats in practice is an area of ongoing research. 1 View
82 971 Ensure that personal data is protected Internet Research Task Force (IRTF) Thing-to-Thing Research Group (T2TRG) State-of-the-Art and Challenges for the Internet of Things Security 5.6 An IoT device user/owner would like to monitor and verify its operational behavior. For instance, the user might want to know if the device is connecting to the server of the manufacturer for any reason. This feature - connecting to the manufacturer's server – may be necessary in some scenarios, such as during the initial configuration of the device. However, the user should be kept aware of the data that the device is sending back to the vendor. For example, the user might want to know if his/her TV is sending data when he/she inserts a new USB stick. 1 View
83 970 Ensure that personal data is protected International Electrotechnical Commission (IEC) IoT 2020: Smart and secure IoT platform 5.2.2.1.3 Performance requirements of future IoT systems will result in scenarios in which computations on data collected from devices will have to be executed as close as possible to devices. Often, those domains may not meet the security requirements of the data owner, i.e. the data should not be disclosed to the component of the IoT system which processes it. Thus mechanisms are required which will make it possible to protect the confidentiality and integrity of data, while still allowing execution of computations and production of meaningful results for the data owner. 1 View
84 969 Ensure that personal data is protected Intel Policy Framework for the Internet of Things (IoT) Privacy and Security Optimal privacy and security methods must be developed as required for different IoT solutions. Use cases should be used to proactively identify privacy and security risks and to develop robust strategies to mitigate those risks. 1 View
85 968 Ensure that personal data is protected Intel Policy Framework for the Internet of Things (IoT) Privacy and Security The IoT presents new challenges for traditional privacy principles. Consumer notice and consent will continue to be important, however other privacy principles must also be emphasized to ensure consumer privacy is adequately protected. For example, focusing on accountability for the appropriate collection, use, and protection of the consumer’s data. 1 View
86 967 Ensure that personal data is protected Intel Policy Framework for the Internet of Things (IoT) Privacy and Security Privacy and security are critical building blocks for our nation’s IoT ecosystem – and capabilities that must be designed into our IoT systems from the outset using the best known Privacy-by-Design methodologies. 1 View
87 966 Ensure that personal data is protected Industrial Internet Consortium (IIC) Industrial Internet of ThingsVolume G4: Security Framework v1.0 8.8.1 DATA CONFIDENTIALITY. Data confidentiality refers to ensuring that information is not disclosed to unauthorized parties. To implement this, cryptography renders data unintelligible to unauthorized entities that do not have the proper key for decryption of the data. The algorithm must be designed and implemented to ensure that no unauthorized party can determine the keys associated with the encryption or derive the plaintext. Data confidentiality is often mandated by regulations, in particular when privacy of the records is important or the record contains personally identifiable information (PII).Some fields in a record may contain sensitive data that requires confidentiality while other fields need to be processed by an application. In this case, data tokenization can replace sensitive fields or the value can be modified so confidentiality and privacy of those fields is preserved 1 View
88 965 Ensure that personal data is protected IERC-European Research Cluster on the Internet of Things (IERC) IoT Governance, Privacy and Security Issues - IERC Position Paper The same ability of third parties to know that two entities are exchanging data can be a violation of privacy. Both users and services might need to operate in given scenarios without releasing identification, addressing or other sensitive information the other endpoint. This can be in conflict with the some requirements related to authentication, authorization and non-repudiation. Using Pseudonymization 1 View
89 964 Ensure that personal data is protected IERC-European Research Cluster on the Internet of Things (IERC) IoT Governance, Privacy and Security Issues - IERC Position Paper Context-sharing enabled objects must be able to answer the question which information should be shared with whom. This question can be automatically answered, if the object has a fine-grained privacy policy that contains both the trusted objects and the context characteristics allowed for sharing. Additionally, an object needs mechanisms that enforce this policy. The contents of a policy are typically user and thus, object dependent. Many users have different opinions about what kind of context should be regarded as private and not every object supports all types of context. As a consequence, we can expect that some policies might be more restrictive than others. Secure Middleware based on policy management 1 View
90 963 Ensure that personal data is protected IERC-European Research Cluster on the Internet of Things (IERC) IoT Governance, Privacy and Security Issues - IERC Position Paper Stick flow policies combine sticky policies for data with their flow policies, i.e. a data item in a system using this technology is annotated with a security policy which describes how a data item can be used and which conditions have to be satisfied before an item can flow to another entity. Sticky Flow Policies 1 View
91 962 Ensure that personal data is protected IEEE IoT Security Principles and Best Practices 9 The basic idea of IoT is to connect everyday objects via Internet or ad-hoc network. IoT devices provide services that are discoverable by other IoT devices. Most of the protocols leak sensitive personally identifiable information (PII,) like owner's name or information that may be linkable to an individual, like a device’s host name. This information can be linked to other information sources to target attacks. Service mechanisms and authentication protocols are required so that only authorized clients can discover the device. Protect sensitive information 1 View
92 961 Ensure that personal data is protected GSMA IoT Security Guidelines for Service Ecosystems CLP12_8.3 All users must be able to control what information they offer to third parties, through service APIs. The information should be classified into types of data, and attributed with security classifications. Users should be able to retrieve the types of data and classifications that are used in the modelling of their account. The user should be able to apply constraints to the types of data, to allow them to grant or revoke access to this data to Partners. This can come in the form of an authenticated API, or a GUI that allows simple Yes or No controls on a general, and per-Partner basis. Low Priority 1 View
93 960 Ensure that personal data is protected GSMA IoT Security Guidelines for Service Ecosystems CLP12_7.4 After security classifications have been defined, and data types have been attributed a valid classification, and a breach policy has been enacted, a data distribution policy should be generated. A data distribution policy describes how information should be processed through technical controls and out to service applications that have been granted permission to access the data. The permissions model is a part of the data distribution policy, and pairs with the user’s ability to create granular data permissions. Medium PriorityData distribution policies enforce security requirements on partners who may not adhere to the same level of security internally as the IoT Service Provider does. Since the IoT Service Provider cannot control the security a partner has implemented in their internal services and network, the IoT Service Provider can only enforce that data contributed to a partner is trafficked in a secure manner. Without this definition, the partner can enforce insecure configurations that may expose user data to adversaries while the data is still under the control of the IoT Service Provider. By enforcing stringent security controls for the communications channel, the IoT Service Provider proves it is doing everything it can do to enforce security until the data is out of its control. 1 View
94 959 Ensure that personal data is protected GSMA IoT Security Guidelines for Service Ecosystems CLP12_6.7 Defining policies and procedures for the classification of data is not enough. There must also be a model for detecting whether the data has been exposed by a Partner. The organization must have a plan in place to evaluate whether a Partner was involved in business practices that breach the technological controls or policies set in place to guard user’s data and privacy. High Priority 1 View
95 958 Ensure that personal data is protected GSMA IoT Security Guidelines for Service Ecosystems CLP12_6.1 While the privacy model deals with the way user’s information is offered to Partners, theauthorization model defines how the business or Partners will act on behalf of a user. This,for instance, would come in handy for a home automation system where a Partner’s metricscould optimize the use of heating or cooling in a given home. The authorization model wouldgrant the Partner the ability to change heating or cooling controls for that user’s home whencertain metrics were detected by the Partner. Without an Authorization Model, third parties will not have restricted access to a user’scapabilities. This may allow a rogue or compromised third party to acquire full access to auser’s technology or data. By creating an authorization model, access is restricted to onlythe attributes that a user will allow. This enables the user to have greater control over whatcapabilities and data are made available to third parties, and reduces the risk of the IoTService Provider by mitigating the potential for widespread compromise. 1 View
96 957 Ensure that personal data is protected GSMA IoT Security Guidelines for Service Ecosystems CLP12_5.12 After defining security classifications, the organization should define types of data to be used by the overall IoT product or service. This will enable the organization to clearly define what types of information are acquired, generated, and disseminated to peers in the IoT system, and how the organization should treat these types of data. This data will provide context and value to the overall components used throughout the IoT environment.While this document will not attempt to model all variations of data that may be relevant to a specific organization, certain types may be as follows:•Users•Actions•Images•Editable documents•Personally-Identifiable Information•Protected Health Information Critical 1 View
97 956 Ensure that personal data is protected GSMA IoT Security Guidelines for Service Ecosystems CLP12_5.11 To properly manage interactions with Partner organizations effectively, security classifications must be defined. This will set the tone for not only the internal organizational policy on data security, but will help define the level of security Partner organizations apply to the business’s data, their own data, and customer’s data. Critical 1 View
98 955 Ensure that personal data is protected GSMA IoT Security Guidelines for Service Ecosystems CLP12_8.3 Build an API for Users to Control Privacy Attributes. All users must be able to control what information they offer to third parties, through serviceAPIs. The information should be classified into types of data, and attributed with securityclassifications. Users should be able to retrieve the types of data and classifications that areused in the modelling of their account. The user should be able to apply constraints to thetypes of data, to allow them to grant or revoke access to this data to Partners. Low priority 1 View
99 954 Ensure that personal data is protected GSMA IoT Security Guidelines Endpoint Ecosystem CLP13_7.7 An imperative aspect of IoT technology is their ability to connect the physical world to the digital world. The result of this is a gap in privacy, as the user’s physical environment is directly associated with the things they like and view online. This may cause undesirable effects over time.As a result, it is important that IoT Service Providers consider the privacy of their consumers and develop Privacy Management interfaces that are integrated into both the Endpoint, where possible, and the product or service’s web interface.This technology should allow the user to determine what attributes of their privacy are being utilized by the system, what the Terms of Service are, and the ability to turn off the exposure of this information to the business or its partners. This granularity and opt-out system will help to ensure that users have the right and the ability to control the information that they share about themselves and their physical world. High priority recommendation by GSMA 1 View
100 953 Ensure that personal data is protected GSMA GSMA IoT Security Assessment CLP11_6 Privacy Considerations Mapping done by GSMA 1 View
101 952 Ensure that personal data is protected European Union Agency for Network and Information Security (ENISA) Security and Resilience of Smart Home Environments 7.1 Users shall verify the authorisations given to devices and services for data access and data exchange. This is particularly true in case of an update where access rights may be modified without user’s consent. For example, devices and services can display a comprehensive view of their communications with external devices and services, their requirement to use private data, etc. Protection of data exchanges 1 View
102 951 Ensure that personal data is protected European Union Agency for Network and Information Security (ENISA) Security and Resilience of Smart Home Environments 5.2, fourth bullet point User data protection: the integrity, confidentiality and authenticity of user data must be protected. Confidentiality protection must be defined with regards to privacy issues. 1 View
103 950 Ensure that personal data is protected European Union Agency for Network and Information Security (ENISA) Baseline Security Recommendations for IoT GP-TM-29 Data integrity and confidentiality must be enforced by access controls. When the subject requesting access has been authorised to access particular processes, it is necessary to enforce the defined security policy. The effectiveness and the strength of access control depend on the correctness of the access control decisions (e.g., how the security rules are configured) and the strength of access control enforcement (e.g., the design of software management or hardware security). Annex A: Detailed Security measures / Good practices 1 View
104 949 Ensure that personal data is protected European Union Agency for Network and Information Security (ENISA) Baseline Security Recommendations for IoT GP-PS-08 Privacy must be a guiding principle when designing anddeveloping systems, in order to make privacy an integral part of thesystem. Annex A: Detailed Security measures / Good practices 1 View
105 948 Ensure that personal data is protected European Union Agency for Network and Information Security (ENISA) Baseline Security Recommendations for IoT GP-OP-13 Only share consumers’ personal data with third partieswith consumers’ affirmative consent, unless required and limited forthe use of product features or service operation. Require that thirdpartyservice providers are held to the same polices including holdingsuch data in confidence and notification requirements of any dataloss/breach incident and/or unauthorised access. Annex A: Detailed Security measures / Good practices 1 View
106 947 Ensure that personal data is protected European Union Agency for Network and Information Security (ENISA) Baseline Security Recommendations for IoT GP-OP-12 Data processed by a third-party (i.e., if the organisationutilises a cloud email provider), must be protected by a dataprocessing agreement with the third-party. With the transference ofdata, the responsibility of protecting that data also should betransferred and compliance verified. Annex A: Detailed Security measures / Good practices 1 View
107 946 Ensure that personal data is protected European Union Agency for Network and Information Security (ENISA) Baseline Security Recommendations for IoT GP-TM-14 Users of IoT products and services must be able toexercise their rights to information, access, erasure, rectification,data portability, restriction of processing, objection to processing,and their right not to be evaluated on the basis of automatedprocessing. Annex A: Detailed Security measures / Good practices 1 View
108 945 Ensure that personal data is protected European Union Agency for Network and Information Security (ENISA) Baseline Security Recommendations for IoT GP-TM-13 IoT stakeholders must be compliant with the EU GeneralData Protection Regulation (GDPR). The complex mesh ofstakeholders involved asks for/implies the necessity of a preciseallocation of legal responsibilities among them with regard to theprocessing of the individual’s personal data, based on the specificitiesof their respective interventions. Annex A: Detailed Security measures / Good practices 1 View
109 944 Ensure that personal data is protected European Union Agency for Network and Information Security (ENISA) Baseline Security Recommendations for IoT GP-TM-12 Minimise the data collected and retained. Many IoTstakeholders only need aggregated data and have no need of the rawdata collected by IoT devices. Stakeholders must delete raw data assoon as they have extracted the data required for their dataprocessing. As a principle, deletion should take place at the nearestpoint of data collection of raw data (e.g. on the same device afterprocessing). Annex A: Detailed Security measures / Good practices 1 View
110 943 Ensure that personal data is protected European Union Agency for Network and Information Security (ENISA) Baseline Security Recommendations for IoT GP-TM-11 Make sure that personal data is used for the specifiedpurposes for which they were collected, and that any furtherprocessing of personal data is compatible and that the data subjectsare well informed. Annex A: Detailed Security measures / Good practices 1 View
111 942 Ensure that personal data is protected European Union Agency for Network and Information Security (ENISA) Baseline Security Recommendations for IoT GP-TM-10 Personal data must be collected and processed fairly andlawfully. The fairness principle specifically requires that personal datashould never be collected and processed without the data subject’sconsent. Annex A: Detailed Security measures / Good practices 1 View
112 941 Ensure that personal data is protected European Telecommunications Standards Institute (ETSI) Cyber Security for Consumer Internet of Things Provision 4.8-3 Consumers who gave consent for the processing of their personal data shall be given the opportunity to withdraw it at any time. 2 View
113 940 Ensure that personal data is protected European Telecommunications Standards Institute (ETSI) Cyber Security for Consumer Internet of Things Provision 4.8-2 Where personal data is processed on the basis of consumers' consent, this consent shall be obtained in a valid way. 2 View
114 939 Ensure that personal data is protected European Telecommunications Standards Institute (ETSI) Cyber Security for Consumer Internet of Things Provision 4.8-1 Device manufacturers and service providers shall provide consumers with clear and transparent information about how their personal data is being used, by whom, and for what purposes, for each device and service. This also applies to third parties that can be involved, including advertisers. 2 View
115 938 Ensure that personal data is protected European Telecommunications Standards Institute (ETSI) Cyber Security for Consumer Internet of Things 4.8 Ensure that personal data is protected 2 View
116 937 Ensure that personal data is protected European Commission and AIOTI Report on Workshop on Security & Privacy in IoT 1) 2) Transparency and user interface control – empower the user to obtain sufficient knowledge on what its devices and related system are doing and sharing, even if it concerns M2M communications and transactions 1 View
117 936 Ensure that personal data is protected European Commission and AIOTI Report on Workshop on Security & Privacy in IoT 1) 1) Data control by the user – in any phase of the data life cycle and product life cycle 1 View
118 935 Ensure that personal data is protected Cloud Security Alliance (CSA) Security Guidance for Early Adopters of the Internet of Things (IoT) 5.3.3 Limit the data that is being collected or aggregated by a gateway to what is really necessary. 1 View
119 934 Ensure that personal data is protected Cloud Security Alliance (CSA) Security Guidance for Early Adopters of the Internet of Things (IoT) 5.1.5 Stakeholders should be able to easily identify the data collected from them for any particular IoT system, as well as the planned or potential uses for that data. Stakeholders should also be allowed to opt in to data collection, at both a coarse and granular level. 1 View
120 933 Ensure that personal data is protected Cloud Security Alliance (CSA) Security Guidance for Early Adopters of the Internet of Things (IoT) 5.1.4 Within the IoT, data collected will have a long lifespan. It is important to consider the full lifespan of the data collected, both within the collecting organization and within any third parties to which it is provided. Stakeholders should be made aware of when data is provided to third parties, the controls used to secure it, and how and when the data is disposed of 1 View
121 932 Ensure that personal data is protected Cloud Security Alliance (CSA) Security Guidance for Early Adopters of the Internet of Things (IoT) 5.1.1 Users of IoT systems should be made aware of all of the data collected from or about them, and should be given the opportunity to opt out of data collection practices at a granular level. Recognizing the concerns that many of the IoT devices may not have proper user interface, companies should find suitable methods to provide the choice and notice to consumers. 1 View
122 931 Ensure that personal data is protected City of New York (NYC) Guidelines for the Internet of Things Privacy + Transparency 1.6 Before any sensitive, private, or confidential data is shared outside the originating City agency, the agency should ensure that the need cannot be met by using anonymized or aggregated data and that the appropriate protections are in place to preserve the confidentiality of the data. 1 View
123 930 Ensure that personal data is protected City of New York (NYC) Guidelines for the Internet of Things Privacy + Transparency 1.5 PII data types should have a clearly associated retention policy and disposal procedure. Sensitive, private or confidential data should be kept for no longer than is operationally necessary or required for the specified, explicit and legitimate purposes. 1 View
124 929 Ensure that personal data is protected City of New York (NYC) Guidelines for the Internet of Things Privacy + Transparency 1.4 PII should by default be anonymized before being shared in any way that could make the information publicly searchable or discoverable. Any copies and reproductions must have the same or higher level of classification as the original. Any combinations of data should be reclassified according to the City’s Data Classification Policy. 1 View
125 928 Ensure that personal data is protected City of New York (NYC) Guidelines for the Internet of Things Privacy + Transparency 1.3 Data and information collected by IoT devices should be classified and treated accordingly, per the City of New York’s Data Classification Policy, as Public, Sensitive, Private or Confidential. All personally identifiable information (PII) should be classified at a minimum as private. All data that is classified as being confidential, or personally identifiable, should be protected from unauthorized use and disclosure. 1 View
126 927 Ensure that personal data is protected City of New York (NYC) Guidelines for the Internet of Things Privacy + Transparency 1.1 The City should make processes and policies related to IoT and IoT-related data publicly available in an up-to-date, clear and comprehensive manner. IoT principles, guidelines, operational policies and responsibilities should be transparent and made public via a City government website. 1 View
127 926 Ensure that personal data is protected Cellular Telecommunications Industry Association (CTIA) CTIA Cybersecurity Certification Test Plan for IoT Devices 4.1 Terms of Service and Privacy Policies Test Confirm that Terms of Service and privacy policy for the device are available. 3 View
128 925 Ensure that personal data is protected Cellular Telecommunications Industry Association (CTIA) CTIA Cybersecurity Certification Test Plan for IoT Devices 3.1 Terms of Service and Privacy Policies Test Confirm that Terms of Service and privacy policy for the device are available. This test ensures the manufacturer provides the lifetime of the product as well as make the customer aware of their privacy policy and where data might be stored outside of the device. 3 View
129 924 Ensure that personal data is protected Broadband Internet Technical Advisory Group (BITAG) Internet of Things (IoT) Security and Privacy Recommendations 7.7 IoT Devices Should Ship with a Privacy Policy That is Easy to Find & Understand. BITAG recommends that IoT devices ship with a privacy policy, but that policy must be easy for a typical user to find and understand. 1 View
130 923 Ensure that personal data is protected Atlantic Council Scowcroft Center for Strategy and Security Smart Homes and the Internet of Things Describe the ways in which customer data is used or will be used, as well as methods for consumers to opt out. This includes change in ownership of the company, or sharing information with third-parties. Informed consent for data use 1 View
131 922 Ensure that personal data is protected Alliance for Internet of Things Innovation (AIOTI) AIOTI Digitisation of Industry Policy Recommendations 3.32 (ii) Second bullet point Implement privacy enhancing techniques such as data segmentation, segregation, aggregation, pseudonymisation, tokENISAtion and anonymization to the extent possible. 1 View
132 921 Ensure that personal data is protected Alliance for Internet of Things Innovation (AIOTI) AIOTI Digitisation of Industry Policy Recommendations 3.32 (ii) First bullet point Promote transparency about what data is collected (including passive collection in smart spaces and smart cities) and do so in a way which is clear and simple for the user Data Management 1 View
133 920 Ensure that personal data is protected Alliance for Internet of Things Innovation (AIOTI) Workshop on Security and Privacy in the Hyper connected World Awareness & Information Supplied with Indication of Purpose Technically regulating access to data to define who can use it for what purpose, and how that can be made transparent, and subsequently measured and monitored. Design in a transparent way, so the data subject is and remains clear and aware of privacy issues, choices it makes and possible consequences thereof. 1 View
134 919 Ensure that personal data is protected Alliance for Internet of Things Innovation (AIOTI) Workshop on Security and Privacy in the Hyper connected World Manufacturer-Implemented Parametrization Rights management for accessing data controlled by the user based on the assessment where and when a Thing or IoT ecosystems in its lifecycle comes into contact with personal data, creates/derives (new) personal data, or otherwise processes personal data, while keeping in my mind the contextuality of purposes and use, as well as multi-purpose Things and IoT ecosystems. 1 View
135 918 Ensure that personal data is protected Alliance for Internet of Things Innovation (AIOTI) Workshop on Security and Privacy in the Hyper connected World Basic Requirements on PRACTICAL PRIVACY IN IoT No Personal Data by Default, ‘As-If’ by Design & De-Identification by DefaultData minimalisation starts with only requesting, collecting, obtaining, deriving and processing personal data to the extent necessary (need-to-know principle), and. The ‘As-If’ principle it to design and engineer ecosystems in IoT as if these will (now or in a later phase) process personal data. The As-If principle is closely related to the privacy by design and privacy by default principles. Design de-Identification capabilities so personal data is de-identified as soon as legally possible. 1 View
136 917 Ensure that personal data is protected Alliance for Internet of Things Innovation (AIOTI) Report: Working Group 4 – Policy 5 5. Respect for User Privacy – Keep it User-CentricAbove all, Privacy by Design requires architects and operators to keep the interests of the individual uppermost by offering such measures as strong privacy defaults, appropriate notice, and empowering user-friendly options. 1 View
137 916 Ensure that personal data is protected Alliance for Internet of Things Innovation (AIOTI) Report: Working Group 4 – Policy 5 3. End-to-End Security – Full Lifecycle Protection Privacy by Design extends throughout the entire lifecycle of the data involved, from start to finish. This ensures that at the end of the process, all data are securely destroyed, in a timely fashion. 1 View
138 915 Ensure that personal data is protected Alliance for Internet of Things Innovation (AIOTI) Report: Working Group 4 – Policy 5 2. Privacy as the Default SettingPrivacy by Design seeks to deliver the maximum degree of privacy by ensuring that personal data are automatically protected in any given IT system or business practice. If an individual does nothing, their privacy still remains intact. No action is required on the part of the individual to protect their privacy – it is built into the product, by default. 1 View
139 914 Ensure that personal data is protected Alliance for Internet of Things Innovation (AIOTI) Report: Working Group 4 – Policy 5 1. Proactive not Reactive;Preventative not Remedial Privacy by Design is characterised by proactive rather than reactive measures. It anticipates and prevents privacy-invasive events before they happen. It does not wait for privacy risks to materialise, nor does it offer remedies for resolving privacy infractions once they have occurred – it aims to prevent them from occurring. 1 View
140 913 Ensure software integrity US National Institute of Standards and Technology (NIST) NIST SP.800-160 Systems Security Engineering F.4.2 Defense in Depth. Defense in depth describes security architectures constructed through the application of multiple mechanisms to create a series of barriers to prevent, delay, or deter an attack by an adversary. 1 View
141 912 Ensure software integrity US National Institute of Standards and Technology (NIST) NIST SP.800-160 Systems Security Engineering F.2.3 Self-Analysis. The principle of self-analysis states that a component must be able to assess its internal state and functionality to a limited extent at various stages of execution, and that this self-analysis capability must be commensurate with the level of trustworthiness invested in the system. At the system level, self-analysis can be achieved via hierarchical trustworthiness assessments established in a bottom up fashion. In this approach, the lower-level components check for data integrity and correct functionality (to a limited extent) of higher-level components. For example, trusted boot sequences involve a trusted lower-level component attesting to the trustworthiness of the next higher-level components so that a transitive chain of trust can be established. 1 View
142 911 Ensure software integrity US National Institute of Standards and Technology (NIST) NIST SP.800-160 Systems Security Engineering F.1.16 Self-Reliant Trustworthiness. The principle of self-reliant trustworthiness states that systems should minimize their reliance on other systems for their own trustworthiness. A system should be trustworthy by default with any connection to an external entity used to supplement its function. 1 View
143 910 Ensure software integrity US National Institute of Standards and Technology (NIST) NIST SP.800-160 Systems Security Engineering F.1.8 Secure Evolvability. The principle of secure evolvability states that a system should be developed to facilitate the maintenance of its security properties when there are changes to its functionality structure, interfaces, and interconnections (i.e., system architecture) or its functionality configuration (i.e., security policy enforcement). These changes may include for example: new, enhanced, and upgraded system capability; maintenance and sustainment activities; and reconfiguration. Although it is not possible to plan for every aspect of system evolution, system upgrades and changes can be anticipated by analyses of mission or business strategic direction; anticipated changes in the threat environment; and anticipated maintenance and sustainment needs. 1 View
144 909 Ensure software integrity UL IoT Security Top 20 Design Principles 12 Implement a power-on self-test that validates core functions and integrity of firmware prior to execution. Implement a cryptographic chain of trust from the hardware during boot where possible Ideally firmware should be validated on each boot to ensure it has not been altered since being installed. This can be achieved when there is a signature across all firmware anyway, which may be the case if the system runs a simple function executive, but is significantly more difficult when it is a complex operating system (OS), such as Linux. Validating all of the different files, scripts, etc. that go into ensuring a complex OS runs correctly is complicated. Potential solutions include the validation of the device bootloader (from a hardware root of trust, which requires support in the processor being used) and then using that bootloader to validate an OS image which is unpacked and installed. Of course, this all takes time. But it is useful to prevent things like Ransomware which may look to install software that renders a device inoperative until a ransom amount is paid. 3 View
145 908 Ensure software integrity Symantec An Internet of Things Security Reference Architecture In powering up, each device boots and runs some code. In that context, it is crucial that we ensure devices only do what we programmed them to do, and ensure that others cannot reprogram them to behave maliciously. In other words, the first step in protecting a device is to protect the code to be sure the device only boots and runs code that you want it running. Fortunately, many chipmakers already build “secure boot” capabilities into their chips. Similarly, for “higher level” code, a number of time-proven, opensource, and client-side libraries like OpenSSL can easily be used to check signatures of code, and accept code only if it comes from an authorized source. In that context, signing firmware, boot images, and higherlevel embedded code are all increasingly common, including signing the underlying software components such as any operating system, and not just applications, but all code on the device. This approach can ensure that all critical components, sensors, actuators, controllers, and relays are all properly configured to only run signed code and never run unsigned code. Protecting DevicesProtecting the Code that Drives IoT 1 View
146 907 Ensure software integrity Software and Information Industry Association (SIIA) Empowering the Internet of Things: Benefits 6 Policies for Embedded Software Should Provide for Product Integrity Unrestricted ability to access and modify embedded software will threaten the reliability, safety and usability of IoT devices. In many cases, ensuring the product’s integrity will require users to abide by the terms of software licenses and other contractual terms. This principle of product integrity is critical to the full development of the IoT’s economic and social potential, and it is one that existing law generally respects. 1 View
147 906 Ensure software integrity PSA Certified Critical security questions for chip vendors, OS providers and OEMs D1.1 The device is configured to enforce trusted boot for RTOS and updateable PSA-RoT. Each updatable component is measured and validated prior execution. For OEM 3 View
148 905 Ensure software integrity PSA Certified Critical security questions for chip vendors, OS providers and OEMs R2.1 The RTOS protects in integrity the Device ID. For RTOS Vendors 3 View
149 904 Ensure software integrity PSA Certified Critical security questions for chip vendors, OS providers and OEMs C1.2 The chip provides trusted boot support, initiated from immutable code. For Chip Vendors 3 View
150 903 Ensure software integrity PSA Certified Critical security questions for chip vendors, OS providers and OEMs C1.1 The chip has a hardware mechanism to isolate the Secure Processing Environment (SPE) and related assets from the NonSecure Processing Environment. For Chip Vendors 3 View
151 902 Ensure software integrity Open Connectivity Foundation (OCF) OCF Security Specification v2.0.1 14.3.3.1 To qualify as high robustness secure boot process, the signature and hash algorithms shall be one of the approved algorithms, the signature values and the keys used for verification shall be stored in secure storage and the algorithms shall run inside a secure execution environment and the keys shall be provided the SEE over trusted path. 3 View
152 901 Ensure software integrity Open Connectivity Foundation (OCF) OCF Security Specification v2.0.1 14.3.2 When performing a secure boot, it is required that the integrity of each boot loader is verified before executing the boot loader stage. As mentioned, while the signature and verification key for the lowest level bootloader is typically stored in tamper-proof memory, the signature and verification key for higher levels should be embedded (but attached in an easily accessible manner) in the data structures software. 3 View
153 900 Ensure software integrity Open Connectivity Foundation (OCF) OCF Security Specification v2.0.1 14.3.1 In order to ensure that all components of a Device are operating properly and have not been tampered with, it is best to ensure that the Device is booted properly. There may be multiple stages of boot. The end result is an application running on top an operating system that takes advantage of memory, CPU and peripherals through drivers. 3 View
154 899 Ensure software integrity Open Connectivity Foundation (OCF) OCF Security Specification v2.0.1 14.2.5 Many security functions depend on time-sensitive credentials. Examples are time stamped 4390 Kerberos tickets, OAUTH tokens, X.509 certificates, OSCP response, software upgrades, etc. 4391 Lack of secure source of clock can mean an attacker can modify the system clock and fool the 4392 validation mechanism. Thus an SEE needs to provide a secure source of time that is protected 4393 from tampering. Trustworthiness from security robustness standpoint is not the same as accuracy. 4394 Protocols such as NTP can provide rather accurate time sources from the network, but are not 4395 immune to attacks. A secure time source on the other hand can be off by seconds or minutes 4396 depending on the time-sensitivity of the corresponding security mechanism. Secure time source 4397 can be external as long as it is signed by a trusted source and the signature validation in the 4398 local Device is a trusted process (e.g. backed by secure boot). 3 View
155 898 Ensure software integrity Open Connectivity Foundation (OCF) OCF Security Specification v2.0.1 14.2.2.4 9) Device vendor understands that if an application running on the Device has access to cryptographic elements such as the private keys or Ownership Credential, then those elements have become vulnerable. If the Device vendor is implementing a Bridge, an OBT, or a Device with access to the Internet beyond the local network, the execution of critical functions should take place within a Trusted or Secure Execution Environment (TEE/SEE). 3 View
156 897 Ensure software integrity Open Connectivity Foundation (OCF) OCF Security Specification v2.0.1 14.2.2.4 2) Secure download and boot – To prevent the loading and execution of malicious software, where it is practical, it is recommended that Secure Download and Secure Boot methods that authenticate a binary’s source as well as its contents be used. 3 View
157 896 Ensure software integrity Open Connectivity Foundation (OCF) OIC Security Specification v1.1.1 15.1.1.3 Secure download and boot – To prevent the loading and execution of malicious software, where it is practical, it is recommended that Secure Download and Secure Boot methods that authenticate a binary’s source as well as its contents be used. Additional Security Guidelines and Best Practices 1 View
158 895 Ensure software integrity Open Connectivity Foundation (OCF) OIC Security Specification v1.1.1 15.2.1 In order to ensure that all components of a device are operating properly and have not been tampered with, it is best to ensure that the device is booted properly. There may be multiple stages of boot. The end result is an application running on top an operating system that takes advantage of memory, CPU and peripherals through drivers. Concept of software module authentication. 1 View
159 894 Ensure software integrity Microsoft IoT Security Best Practices Integrate with care Many software security flaws exist at the boundary of libraries and APIs. Functionality that may not be required for the current deployment might still be available via an API layer. To ensure overall security, make sure to check all interfaces of components being integrated for security flaws. 1 View
160 893 Ensure software integrity Microsoft IoT Security Best Practices Choose open-source software with care Open-source software provides an opportunity to quickly develop solutions. When you're choosing open-source software, consider the activity level of the community for each open-source component. An active community ensures that software is supported and that issues are discovered and addressed. Alternatively, an obscure and inactive open-source software project might not be supported and issues are not likely be discovered. 1 View
161 892 Ensure software integrity Microsoft IoT Security Best Practices Follow secure software development methodology Development of secure software requires ground-up thinking about security, from the inception of the project all the way to its implementation, testing, and deployment. The choices of platforms, languages, and tools are all influenced with this methodology. The Microsoft Security Development Lifecycle provides a step-by-step approach to building secure software. 1 View
162 891 Ensure software integrity Korea Internet & Security Agency (KISA) IoT Security Certification Service (IoT-SAP) PL2-3 Integrity test must be conducted before an update execution. 3 View
163 890 Ensure software integrity Korea Internet & Security Agency (KISA) IoT Security Certification Service (IoT-SAP) PL2-2 Rollback function must be provided in case of an update failure. 3 View
164 889 Ensure software integrity IoT Security Initiative Security Design Best Practices Make use of secure boot, secure micro-kernels and hardware virtualization capabilities whenever possible. 1 View
165 888 Ensure software integrity IoT Security Initiative Security Design Best Practices Fingerprint and validate the integrity of critical system operating thresholds or parameters. 1 View
166 887 Ensure software integrity IoT Security Foundation IoT Security Compliance Framework 2.0 2.4.14.5 Where a product includes a trusted Secure Boot process, the entire production test and any related calibration is executed with the processor system operating in its secured boot, authenticated software mode. 3 View
167 886 Ensure software integrity IoT Security Foundation IoT Security Compliance Framework 2.0 2.4.8.17 Where the product has the ability to remotely recover from attack, it should return to a known good state, to enable safe recovery and updating of the device. 3 View
168 885 Ensure software integrity IoT Security Foundation IoT Security Compliance Framework 2.0 2.4.7.5 If an unauthorised change is detected, the device should alert the consumer/administrator to an issue and should not connect to wider networks than those necessary to perform the alerting function. 3 View
169 884 Ensure software integrity IoT Security Foundation IoT Security Compliance Framework 2.0 2.4.5.18 The build environment and toolchain used to create the software is under configuration management and version control, and its integrity is validated regularly. 3 View
170 883 Ensure software integrity IoT Security Foundation IoT Security Compliance Framework 2.0 2.4.5.9 There are measures to prevent the installation of non-production software onto production devices. 3 View
171 882 Ensure software integrity IoT Security Foundation IoT Security Compliance Framework 2.0 2.4.5.8 The product has protection against unauthorised reversion of the software to an earlier and potentially less secure version. 3 View
172 881 Ensure software integrity IoT Security Foundation IoT Security Compliance Framework 2.0 2.4.5.7 The product’s software signing root of trust is stored in tamper-resistant memory. 3 View
173 880 Ensure software integrity IoT Security Foundation IoT Security Compliance Framework 2.0 2.4.5.6 To prevent the stalling or disruption of the device’s software operation, watchdog timer are present, and cannot be disabled. 3 View
174 879 Ensure software integrity IoT Security Foundation IoT Security Compliance Framework 2.0 2.4.5.1 The product has measures to prevent unauthenticated software and files being loaded onto it. In the event that the product is intended to allow un-authenticated software, such software should only be run with limited permissions and/or in a sandbox. 3 View
175 878 Ensure software integrity IoT Security Foundation IoT Security Compliance Framework 2.0 2.4.4.15 Where production devices have a CPU watchdog, it is enabled and will reset the device in the event of any unauthorised attempts to pause or suspend the CPU’s execution. 3 View
176 877 Ensure software integrity IoT Security Foundation IoT Security Compliance Framework 2.0 2.4.4.4 The Secure Boot process is enabled by default. 3 View
177 876 Ensure software integrity IoT Security Foundation IoT Security Compliance Framework 2.0 2.4.4.3 The product’s processor system has a measured irrevocable hardware Secure Boot process. 3 View
178 875 Ensure software integrity IoT Security Foundation IoT Security Compliance Framework 2.0 2.4.4.2 The product’s processor system has an irrevocable “Trusted Root Hardware Secure Boot”. 3 View
179 874 Ensure software integrity IoT Security Foundation IoT Security Compliance Framework 2.0 2.4.4.1 The product’s processor system has an irrevocable hardware Secure Boot process. 3 View
180 873 Ensure software integrity Internet Society (ISOC) The Internet of Things: An Internet Society Public Policy Briefing Security Ensuring lifetime security in IoT products and services must be a fundamental priority to maintain overall user trust in this technology. Users need to trust that IoT devices and related data services are secure, especially as they become more pervasive and integrated into our daily lives. 1 View
181 872 Ensure software integrity Industrial Internet Consortium (IIC) Industrial Internet of ThingsVolume G4: Security Framework v1.0 8.7.2 RUNTIME INTEGRITY. After the boot-process integrity has been attested to, the OS is running and applications can execute. Runtime integrity controls monitor, and ideally, enforce the integrity of the endpoint beyond the boot process 1 View
182 871 Ensure software integrity Industrial Internet Consortium (IIC) Industrial Internet of ThingsVolume G4: Security Framework v1.0 8.4 ESTABLISH ROOTS OF TRUST. The roots of trust (RoT), or trust roots, consisting of hardware, software, people and organizational processes, establish confidence in the system. An endpoint without a correctly implemented RoT will lack the ability to establish confidence that it will behave as intended.The root of trust on a device determines the level of confidence in the authenticity of the credentials belonging to that particular device. The root of trust should be able to generate, manage and store at least one identity. 1 View
183 870 Ensure software integrity Industrial Internet Consortium (IIC) Industrial Internet of ThingsVolume G4: Security Framework v1.0 8.1 SECURITY THREATS AND VULNERABILITIES ON ENDPOINTS. Vulnerabilities in the Development Environment, ⑮: The introduction of weaknesses during the software development lifecycle can leave the IIoT systems susceptible to attack. These weaknesses may be introduced during architecting, designing, or writing of the code. Use of vulnerable or malicious libraries or untrusted development frameworks may lead to their inclusion in the resulting code running in the IIoT system. 1 View
184 869 Ensure software integrity Industrial Internet Consortium (IIC) Industrial Internet of ThingsVolume G4: Security Framework v1.0 8.1 SECURITY THREATS AND VULNERABILITIES ON ENDPOINTS. Vulnerabilities of the Deployment Process, ⑩: Errors and potential malicious code may also infiltrate the endpoint as part of the deployment process, for example, incorrect or malicious installation scripts, intercepted communications, or unauthorized replacement of a package on the update server. Reduction of possible endpoint configurations in large-scale endpoint deployments will be important in reducing complexity and vulnerabilities in the deployment process. 1 View
185 868 Ensure software integrity Industrial Internet Consortium (IIC) Industrial Internet of ThingsVolume G4: Security Framework v1.0 8.1 SECURITY THREATS AND VULNERABILITIES ON ENDPOINTS. Illicit changes to Application Software or exposed Application Programming Interface (API), ⑥+⑦+⑧+⑨: Endpoint applications are often the target for malware or an attacker seeking to infiltrate and compromise the endpoint. Execution of malicious applications or overriding of application APIs can adversely impact the trustworthiness of the endpoint. Exposed APIs should also be protected against denial of service attack where continuous access from unauthorized users could limit the responsiveness and access to the exposed functionality. 1 View
186 867 Ensure software integrity Industrial Internet Consortium (IIC) Industrial Internet of ThingsVolume G4: Security Framework v1.0 8.1 SECURITY THREATS AND VULNERABILITIES ON ENDPOINTS. Compromises to the Guest OS, Hypervisors and Separation Kernels, ④+⑤: These software layers control allocation of hardware resources to applications. Attacks to these layers can alter the behavior of the system, allow information flows to bypass security controls and enable attackers to gain privileged access to endpoint hardware and software resources. Once access is gained to this layer, attackers will have opportunity to affect the entire software stack and further alter security controls built in to this level. 1 View
187 866 Ensure software integrity Industrial Internet Consortium (IIC) Industrial Internet of ThingsVolume G4: Security Framework v1.0 8.1 SECURITY THREATS AND VULNERABILITIES ON ENDPOINTS. Intercepts or overrides of the system boot process, ②+③: The endpoint boot process can be altered by modifying the firmware interface between the hardware platform firmware and the operating system such as the unified extensible firmware interface (UEFI) or basic Input/output system (BIOS)1. Changes to the bootloader are another threat as changes could compromise the integrity of the endpoint by starting unauthorized or insecure versions of the operating system. Attacks at this level could also affect the normal or secure boot process of the endpoint, the recognition of all the hardware resources and the establishment of a solid root of trust for securing other components.• Compromises to the Guest OS, Hypervisors and Separation Kernels, ④+⑤: These 1 View
188 865 Ensure software integrity Industrial Internet Consortium (IIC) Industrial Internet of ThingsVolume G4: Security Framework v1.0 8.7.1 BOOT PROCESS INTEGRITY. The boot process initializes the main hardware components, and starts the operating system. Trust must be established in the boot environment before any trust in any other software or executable program can be claimed. So the booted environment must be verified and determined to be in an uncompromised state. 1 View
189 864 Ensure software integrity GSMA IoT Security Guidelines for Service Ecosystems CLP12_5.3 In order for an application to run properly, it must be loaded and executed in a consistent way on a reliable, high quality, and secure platform. The TCB defines how to formulate this platform, but the Bootstrap model defines how the application shall be ran on top of it. Critical 1 View
190 863 Ensure software integrity GSMA IoT Security Guidelines Endpoint Ecosystem CLP13_8.4 IoT Endpoints that have user interfaces such as touch screens, rich displays, or alternative interface technologies, must be able to render information to the user and take information from a user in a secure manner.While attributes of the user interface, such as passwords, have already been covered in this document, there are some more subtle issues that must be discussed: Alerting systems Action confirmationWhen an anomaly has occurred, such as physical tampering or an application behaving in an unintended fashion, the user should receive a visible alert. Alternatively, the user should be able to review alerts from the system from within the User Interface. Medium priority recommendation by GSMA (moved from CoP 13 as mapped by GSMA to CoP 7) 1 View
191 862 Ensure software integrity GSMA IoT Security Guidelines Endpoint Ecosystem CLP13_6.12 Do not embed remote administrative capabilities into a publicly accessible application or API, use a separate and distinct communications channel Critical Recommendations by GSMA 1 View
192 861 Ensure software integrity GSMA IoT Security Guidelines Endpoint Ecosystem CLP13_6.16 Critical applications stored in executable regions of memory, such as first-stage bootloaders or Trusted Computing Bases, should be stored read-only. This ensures that the device can be booted into a valid configuration without interjection from an adversary. Without this assurance, executable code loaded after the first stage of execution will not be able to trust that it was booted into a valid configuration or state. Critical recommendation by GSMA 1 View
193 860 Ensure software integrity GSMA IoT Security Guidelines Endpoint Ecosystem CLP13_6.1 Implement a Trusted Computing Base Mapping done by GSMA 1 View
194 859 Ensure software integrity European Union Agency for Network and Information Security (ENISA) Security and Resilience of Smart Home Environments 5.2, sixth bullet point Self-protection: HW and SW self-protection measures should be in place to protect previous security functions. Data used to enforce these security functions should be protected, and hardening should be used to reduce the attack surface 1 View
195 858 Ensure software integrity European Union Agency for Network and Information Security (ENISA) Baseline Security Recommendations for IoT GP-TM-01 Employ a hardware-based immutable root of trust. The Hardware Root of Trust is a trusted hardware component which receives control at power-on. It then extends the chain of trust to other hardware, firmware, and software components. The Root of Trust should then be attestable by software agents running within and throughout the infrastructure. Annex A: Detailed Security measures / Good practices 1 View
196 857 Ensure software integrity European Union Agency for Network and Information Security (ENISA) Baseline Security Recommendations for IoT GP-TM-04 Sign code cryptographically to ensure it has not been Management tampered with after being signed as safe for the device, and implement run-time protection and secure execution monitoring to be sure malicious attacks do not overwrite code after it is loaded. Only run signed code and never unsigned code. Measuring the bootprocess enables the detection of manipulation of the host OS and software, so that malicious changes in the behaviour of the devices can be detected. It enables boot-time detection of rootkits, viruses and worms. Annex A: Detailed Security measures / Good practices 1 View
197 856 Ensure software integrity European Union Agency for Network and Information Security (ENISA) Baseline Security Recommendations for IoT GP-TM-16 Mechanisms for self-diagnosis and self-repair/healing to recover from failure, malfunction or a compromised state. Annex A: Detailed Security measures / Good practices 1 View
198 855 Ensure software integrity European Union Agency for Network and Information Security (ENISA) Baseline Security Recommendations for IoT GP-TM-06 Restore Secure State - Enable a system to return to a state that was known to be secure, after a security breach has occured or if an upgrade has not been successful. Annex A: Detailed Security measures / Good practices 1 View
199 854 Ensure software integrity European Union Agency for Network and Information Security (ENISA) Baseline Security Recommendations for IoT GP-TM-03 The boot process initialises the main hardware components, and starts the operating system. Trust must be established in the boot environment before any trust in any other software or executable program can be claimed, so the booted environment must be verified and determined to be in an uncompromised state. Annex A: Detailed Security measures / Good practices 1 View
200 853 Ensure software integrity European Union Agency for Network and Information Security (ENISA) Baseline Security Recommendations for IoT GP-TM-02 Use hardware that incorporates security features to strengthen the protection and integrity of the device – for example, specialised security chips / coprocessors that integrate security at the transistor level, embedded in the processor, providing, among other things, a trusted storage of device identity and authentication means, protection of keys at rest and in use, and preventing unprivileged from accessing to security 1 View
201 852 Ensure software integrity European Telecommunications Standards Institute (ETSI) Cyber Security for Consumer Internet of Things Provision 4.7-2 If an unauthorized change is detected to the software, the device should alert the consumer and/or administrator to an issue and should not connect to wider networks than those necessary to perform the alerting function. If an IoT device detects something unusual has happened with its software, it will be able to inform the right person. In some cases, devices can have the ability to be in administration mode - for example, there can be a user mode for a thermostat in a room that prevents other settings being changed. In these cases, an alert to the administrator is appropriate as that person has the ability to act on the alert. 2 View
202 851 Ensure software integrity European Telecommunications Standards Institute (ETSI) Cyber Security for Consumer Internet of Things Provision 4.7-1 Software on IoT devices should be verified using secure boot mechanisms, which require a hardware root of trust. 2 View
203 850 Ensure software integrity European Telecommunications Standards Institute (ETSI) Cyber Security for Consumer Internet of Things 4.7 Ensure software integrity 2 View
204 849 Ensure software integrity Cellular Telecommunications Industry Association (CTIA) CTIA Cybersecurity Certification Test Plan for IoT Devices 4.11 Secure Boot Confirm that the device protects the integrity of the boot process. 3 View
205 848 Ensure software integrity CableLabs A Vision for Secure IoT Integrity The data created or received by a device must be trustworthy, and protected from unauthorized modification. This requires that the device identity, execution environment, configuration, and communications are secured using well-established methods. 1 View
206 847 Ensure software integrity CableLabs A Vision for Secure IoT Increasing Security through an Industry-Led Standards-based Approach To further ensure device integrity, each device should be “hardened” to minimize the attack surface by closing unnecessary ports, disabling unnecessary services, and using a secure bootloader with configuration validation 1 View
207 846 Ensure software integrity Broadband Internet Technical Advisory Group (BITAG) Internet of Things (IoT) Security and Privacy Recommendations 7.1 Secure software supply chain. Manufacturers should protect the secure software supply chain to prevent introduction of malware during the manufacturing process; vendors and manufacturers should take appropriate measures to secure their software supply chain. 1 View
208 845 Ensure software integrity Alliance for Internet of Things Innovation (AIOTI) Workshop on Security and Privacy in the Hyper connected World Basic Requirements on APPLICATIONS Third-party librariesRules for maintaining, updates, checking for vulnerabilities. 1 View
209 844 Minimise exposed attack surfaces Web of Things (WoT) Security and Privacy Considerations Minimize Network Interface Functionality 4.1.5 Network interfaces exposed by a TD (WoT Interfaces) should only provide the minimal necessary functionality, which helps to minimize implementation errors, possibilities for exposing potentially sensitive data, DoS attack possibilities etc. Devices should be strongly encapsulated, meaning the network interfaces should not expose implementation details (for example, the use of particular software frameworks). Consider different levels of access for different users. 1 View
210 843 Minimise exposed attack surfaces US National Institute of Standards and Technology (NIST) NIST SP.800-160 Systems Security Engineering F.1.6 Minimized Sharing. The principle of minimized sharing states that no computer resource should be shared between system components (e.g., subjects, processes, functions) unless it is absolutely necessary to do so. Minimized sharing helps to simplify design and implementation. In order to protect user-domain resources from arbitrary active entities, no resource should be shared unless that sharing has been explicitly requested and granted. 1 View
211 842 Minimise exposed attack surfaces US National Institute of Standards and Technology (NIST) NIST SP.800-160 Systems Security Engineering F.2.5 Secure Defaults. The principle of secure defaults states that the default configuration of a system (to include its constituent subsystems, components, and mechanisms) reflects a restrictive and conservative enforcement of security policy. The principle of secure defaults applies to the initial (i.e., default) configuration of a system as well as to the security engineering and design of access control and other security functions that should follow a “deny unless explicitly authorized” strategy. 1 View
212 841 Minimise exposed attack surfaces US National Institute of Standards and Technology (NIST) NIST SP.800-160 Systems Security Engineering F.1.14 Least Privilege. The principle of least privilege states that each component should be allocated sufficient privileges to accomplish its specified functions, but no more. This limits the scope of the component’s actions, which has two desirable effects: the security impact of a failure, corruption, or misuse of the component will have a minimized security impact; and the security analysis of the component will be simplified. 1 View
213 840 Minimise exposed attack surfaces US National Institute of Standards and Technology (NIST) NIST SP.800-160 Systems Security Engineering F.1.13 Minimized Security Elements. The principle of minimized security elements states that the system should not have extraneous trusted components. This principle has two aspects: the overall cost of security analysis and the complexity of security analysis. Trusted components, necessarily being trustworthy, are generally costlier to construct, owing to increased rigor of development processes. They also require greater security analysis to qualify their trustworthiness. 1 View
214 839 Minimise exposed attack surfaces US National Institute of Standards and Technology (NIST) NIST SP.800-160 Systems Security Engineering F.1.12 Hierarchical Protection. The principle of hierarchical protection states that a component need not be protected from more trustworthy components. In the degenerate case of the most trusted component, it must protect itself from all other components. For example, if an operating system kernel is deemed the most trustworthy component in a system, then it must protect itself from all untrusted applications it supports, but the applications, conversely, do not need to protect themselves from the kernel. 1 View
215 838 Minimise exposed attack surfaces US National Institute of Standards and Technology (NIST) NIST SP.800-160 Systems Security Engineering F.1.7 Reduced Complexity. The principle of reduced complexity states that the system design should be as simple and small as possible. A small and simple design will be more understandable, more analyzable, and less prone to error. This principle applies to any aspect of a system, but it has particular importance for security due to the various analyses performed to obtain evidence about the emergent security property of the system. For such analyses to be successful, a small and simple design is essential. Application of the principle of reduced complexity contributes to the ability of system developers to understand the correctness and completeness of system security functions. It also facilitates identification of potential vulnerabilities 1 View
216 837 Minimise exposed attack surfaces UL IoT Security Top 20 Design Principles 19 Create and compile firmware for devices so that it contains only code and systems required for the defined functions. Always remove/disable debug and development features in devices when creating production code The larger the body of code, the greater the chance of undiscovered security flaws. Therefore, it is prudent to remove as much code as possible to limit the chance that a flaw discovered after shipping the product will require patching or other mitigations. This includes code that may not be normally executed; even if the code is not used, having it within the device can lead to security problems down the road. For similar reasons, it is essential to remove debug and development code from the device prior to shipping. This is often done with isolating “ifdef” statements, which can automatically remove such features during compile time. Although it is understandable to want features in the code in case there are problems in production, it is often more likely that such features will become a source of vulnerability as they provide access and information that would not normally be provided in the end-user environment. 3 View
217 836 Minimise exposed attack surfaces UL IoT Security Top 20 Design Principles 16 Implement least privilege in all systems Modern processors often offer different privilege levels, which include potential access to memory and other resources. These features can be used by the software to help secure assets within the device by ensuring only software with the right privilege can access them. The interface to the hardware-level privilege controls of a processor are often managed by the OS, such as Linux, but they can also be controlled even if a device does not use a complex OS (for example, if it uses a simple function executive, or cut-down RToS, instead). Whenever possible, keep the use of root or supervisor-level privileges in embedded systems to an absolute minimum, and maintain secret data, such as cryptographic keys, at the highest level of privilege (hardest to access). Similar rules hold true for apps and cloud-based systems: keep the use of elevated privileges to a minimum, and try to isolate functions as their own user or privilege set. 3 View
218 835 Minimise exposed attack surfaces UL IoT Security Top 20 Design Principles 3 Test the system to be sure it is free of known, exploitable vulnerabilities prior to release The software in connected devices, applications and cloud services are often comprised of various software components, including existing software (such as open-source code and third-party libraries) as well as commonly used protocols and functions (such as databases). Each of these software components may have its own vulnerabilities, and it is important that a check is made for known vulnerabilities before releasing any system. This can be achieved through various software utilities and scanning services for cloud-based systems. In the Payment Card Industry (PCI), for example, look for vendors who have passed the requirements from ASV, which has done a good job of providing a minimum validation of scanning vendors. 3 View
219 834 Minimise exposed attack surfaces U.S. Department of Homeland Security Strategic Principles for Securing The Internet of Things (IoT) Start with basic software security and cybersecurity practices and apply them to the IoT ecosystem in flexible, adaptive, and innovative ways. Build onRecognizedSecurity Practices 1 View
220 833 Minimise exposed attack surfaces U.S. Department of Homeland Security Strategic Principles for Securing The Internet of Things (IoT) Build the device using the most recent operating system that is technically viable and economically feasible. Many IoT devices use Linux operating systems, but may not use the most up-to-date operating system. Using the current operating system ensures that known vulnerabilities will have been mitigated. Incorporate Security at the Design Phase 1 View
221 832 Minimise exposed attack surfaces U.S. Department of Homeland Security Strategic Principles for Securing The Internet of Things (IoT) Use hardware that incorporates security features to strengthen the protection and integrity of the device. For example, use computer chips that integrate security at the transistor level, embedded in the processor, and provide encryption and anonymity. Incorporate Securityat the Design Phase 1 View
222 831 Minimise exposed attack surfaces U.S. Department of Homeland Security Strategic Principles for Securing The Internet of Things (IoT) Build in controls to allow manufacturers, service providers, and consumers to disable network connections or specific ports when needed or desired to enable selective connectivity. Depending on the purpose of the IoT device, providing the consumers with guidance and control over the end implementation can be a sound practice. Connect Carefully and Deliberately 1 View
223 830 Minimise exposed attack surfaces Symantec An Internet of Things Security Reference Architecture System hardening, whitelisting, and application sandboxing can provide network protection, closing back doors, limiting network connectivity by application, and restricting both inbound and outbound traffic flow. This can also provide protection against different exploits, restricting app behavior, protecting the system from buffer overflows and zero day attacks, while preserving control of the device. Such solutions can also be used to prevent unauthorized use of removable media as well as locking down device configuration and settings, while also de-escalating user privileges where needed. Such solutions can also provide auditing and alerting functions, helping monitor logs and security events. Policy based technologies can even be run in environments without the connectivity or processing power required to run traditional signature-based technologies. Protecting DevicesEffective Host-Based Protection for IoT 1 View
224 829 Minimise exposed attack surfaces PSA Certified Critical security questions for chip vendors, OS providers and OEMs D3.3 Functionalities that are not needed for the intended usage of the device are disabled or not installed. For OEM 3 View
225 828 Minimise exposed attack surfaces PSA Certified Critical security questions for chip vendors, OS providers and OEMs D3.1 The device is protected in production against unauthorized use of debug or test features, possibly with rules depending on device lifecycle state. The device erases sensitive user assets and credentials on access to these features. 3 View
226 827 Minimise exposed attack surfaces PSA Certified Critical security questions for chip vendors, OS providers and OEMs D2.1 The device does not expose unnecessary communication ports or communication protocol stack For OEM 3 View
227 826 Minimise exposed attack surfaces PSA Certified Critical security questions for chip vendors, OS providers and OEMs R4.2 Functionalities that are not needed for the intended usage of the RTOS are disabled or not installed. For RTOS Vendors 3 View
228 825 Minimise exposed attack surfaces Open Web Application Security Project (OWASP) IoT Security Guidance I10: Poor Physical Security Ensure the product has the ability to disable external ports such as USB 1 View
229 824 Minimise exposed attack surfaces Open Web Application Security Project (OWASP) IoT Security Guidance I10: Poor Physical Security Ensure the product has the ability to limit administrative capabilities in some fashion, possibly by only connecting locally for admin functions 1 View
230 823 Minimise exposed attack surfaces Open Web Application Security Project (OWASP) IoT Security Guidance I10: Poor Physical Security Ensure the product is tamper resistant 1 View
231 822 Minimise exposed attack surfaces Open Web Application Security Project (OWASP) IoT Security Guidance I10: Poor Physical Security Ensure the firmware of Operating System can not be accessed via unintended methods such as through an unnecessary USB port 1 View
232 821 Minimise exposed attack surfaces Open Web Application Security Project (OWASP) IoT Security Guidance I10: Poor Physical Security Ensure the device is produced with a minimal number of physical external ports (e.g. USB ports) 1 View
233 820 Minimise exposed attack surfaces Open Web Application Security Project (OWASP) IoT Security Guidance I3: Insecure Network Services Ensure all devices do not make network ports and/or services available to the internet via UPnP for example 1 View
234 819 Minimise exposed attack surfaces Open Web Application Security Project (OWASP) IoT Security Guidance I3: Insecure Network Services Ensure all devices operate with a minimal number of network ports active 1 View
235 818 Minimise exposed attack surfaces Open Web Application Security Project (OWASP) OWASP Secure Coding Practices Quick Reference Guide Error Handling and Logging  Do not disclose sensitive information in error responses, including system details, session identifiers or account information Use error handlers that do not display debugging or stack trace information Implement generic error messages and use custom error pages The application should handle application errors and not rely on the server configuration Properly free allocated memory when error conditions occur Error handling logic associated with security controls should deny access by default All logging controls should be implemented on a trusted system (e.g., The server) Logging controls should support both success and failure of specified security events Ensure logs contain important log event data Ensure log entries that include un-trusted data will not execute as code in the intended log viewing interface or software Restrict access to logs to only authorized individuals Utilize a master routine for all logging operations Do not store sensitive information in logs, including unnecessary system details, session identifiers or passwords Ensure that a mechanism exists to conduct log analysis Log all input validation failures Log all authentication attempts, especially failures Log all access control failures Log all apparent tampering events, including unexpected changes to state data Log attempts to connect with invalid or expired session tokens Log all system exceptions Log all administrative functions, including changes to the security configuration settings Log all backend TLS connection failures Log cryptographic module failures Use a cryptographic hash function to validate log entry integrity 1 View
236 817 Minimise exposed attack surfaces Open Connectivity Foundation (OCF) OCF Security Specification v2.0.1 14.2.2.4 8) Device vendor has not implemented test or debug interfaces on the Device which are operable or which can be enabled which might present an attack vector on the Device which circumvents the interface-level security or access policies of the Device. 3 View
237 816 Minimise exposed attack surfaces Open Connectivity Foundation (OCF) OCF Security Specification v2.0.1 14.2.2.4 3) Deprecated algorithms – Algorithms included but not limited to the list below are considered unsecure and shall not be used for any security-related function: a) SHA-1 4325 b) MD5 4326 c) RC4 4327 d) RSA 1024 3 View
238 815 Minimise exposed attack surfaces Open Connectivity Foundation (OCF) OIC Security Specification v1.1.1 15.1.3 Paths/ ports used for data entry into or export out of trusted/ crypto-boundary needs to be protected. This includes paths into and out secure execution engine and secure memory. Path protection can be both hardware based (e.g. use of a privileged bus) or software based (using encryption over an untrusted bus). Trusted input/output paths 1 View
239 814 Minimise exposed attack surfaces Online Trust Alliance (OTA) IoT Security & Privacy Trust Framework v2.5 37 Implement measures to help prevent or make evident any physical tampering of devices. Such measures help to protect the device from being opened or modified for malicious purposes after installation or from being returned to a retailer in a compromised state. Recommended (Should) 1 View
240 813 Minimise exposed attack surfaces Online Trust Alliance (OTA) IoT Security & Privacy Trust Framework v2.5 11 Design devices to minimum requirements necessary for operation. For example, USB ports or memory card slots should only be included if they are required for the operation and maintenance of the device. Unused ports and services should be disabled. Required (Must) 1 View
241 812 Minimise exposed attack surfaces Online Trust Alliance (OTA) IoT Security & Privacy Trust Framework v2.5 9 Ensure all IoT devices and associated software have been subjected to rigorous, standardized software development lifecycle testing including unit, system, acceptance, and regression testing and threat modeling, along with maintaining an inventory of the source for any third-party/open source code and/or components. Employ generally accepted code and system hardening techniques across a range of typical use case scenarios, including prevention of any data leaks between the device, apps and cloud services. Developing secure software requires thinking about security from a project’s inception through implementation, testing, and deployment. Devices should ship with current software and/or on first boot push automatic updates to address any known critical vulnerabilities. Required (Must) 1 View
242 811 Minimise exposed attack surfaces oneM2M TR-0008-V2.0.1 Security (Technical Report) 8.2.5 Processes should be implemented to protect the storage. Therefore it is recommended that least-privileges are implemented so that service privileges are minimized as much as possible to reduce risk. Protection of Storage by Privileges 1 View
243 810 Minimise exposed attack surfaces Object Management Group (OMG) Cloud Standards Customer Council (CSCC) Cloud Customer Architecture for IoT System, Application, and Solution Lifecycle Management Lifecycle management of the IoT system is complex, multi-faceted, and has relationships with identity management, device management, the supply chain, application and software development, through to system operations and change management of deployed and in-service systems. Attention to security in all of these areas is required in order to prevent a variety of attacks ranging from malicious code insertion to inappropriate firmware/software deployment, to effective cryptographic key management. 1 View
244 809 Minimise exposed attack surfaces National Institute of Standards and Technology (NIST) Considerations for a Core IoT Cybersecurity Capabilities Baseline 12 The IoT device is designed to allow physical access to it to be controlled. Physical access control is important for continuously securing devices, but it can be controlled post-market in many ways and in a diverse set of contexts (e.g., placement of devices in inaccessible locations or within more secure enclosures). Physical resilience of a device takes time and expertise to verify. Hardening physical access to internal components should be within the means of manufacturers already executing a product design and development process, but design considerations (e.g., form factor) could make achieving it difficult. This capability would offer limited pre-market utility, could prove difficult to adequately verify, and may be difficult to implement, so it should not be in the core baseline. 3 View
245 808 Minimise exposed attack surfaces National Institute of Standards and Technology (NIST) Considerations for a Core IoT Cybersecurity Capabilities Baseline 11 The IoT device can enforce the principle of least functionality through its design and configuration. Limiting functionality as a general design practice can improve device and data security by limiting the attack surface. Verifying design principles is difficult and requires organizational access. Designing for least functionality or extending a design to allow for functionality configuration may increase the cost and complexity of the device’s development process. Though this capability may offer utility, it would be very difficult to verify and might also be costly to implement, so it should not be in the core baseline. 3 View
246 807 Minimise exposed attack surfaces National Institute of Standards and Technology (NIST) Considerations for a Core IoT Cybersecurity Capabilities Baseline 4 Local and remote access to the IoT device and its interfaces can be controlled. Controlling access is imperative for both ensuring confidentiality of data-at-rest on the device and controlling device behavior, which helps reduce the propensity and impact of attacks that use IoT devices against targets. Testing and verification of access control measures is possible, but may be difficult with diverse devices at scale. Greater access control may increase the complexity of a device or the system it resides in. Though complexity of some devices and systems may increase to provide this capability and verification at scale may be difficult, its utility towards both device and data security indicates it should be in the core baseline. 3 View
247 806 Minimise exposed attack surfaces Microsoft IoT Security Best Practices Physically protect the IoT infrastructure The worst security attacks against IoT infrastructure are launched using physical access to devices. One important safety practice is to protect against malicious use of USB ports and other physical access. One key to uncovering breaches that might have occurred is logging of physical access, such as USB port use. Again, Windows 10 (IoT and other SKUs) enables detailed logging of these events. 1 View
248 805 Minimise exposed attack surfaces Microsoft IoT Security Best Practices Deploy hardware securely IoT deployments may require hardware to be deployed in unsecure locations, such as in public spaces or unsupervised locales. In such situations, ensure that hardware deployment is tamper-proof to the maximum extent. If USB or other ports are available on the hardware, ensure that they are covered securely. Many attack vectors can use these as entry points. 1 View
249 804 Minimise exposed attack surfaces Microsoft IoT Security Best Practices Make hardware tamper proof Build in mechanisms to detect physical tampering, such as opening of the device cover or removing a part of the device. These tamper signals may be part of the data stream uploaded to the cloud, which could alert operators of these events. 1 View
250 803 Minimise exposed attack surfaces Microsoft IoT Security Best Practices Scope hardware to minimum requirements The hardware design should include the minimum features required for operation of the hardware, and nothing more. An example is to include USB ports only if necessary for the operation of the device. These additional features open the device for unwanted attack vectors that should be avoided. 1 View
251 802 Minimise exposed attack surfaces Korea Internet & Security Agency (KISA) IoT Security Certification Service (IoT-SAP) PL4-1 Access to internal ports by an unauthorized person must be prevented. 3 View
252 801 Minimise exposed attack surfaces Korea Internet & Security Agency (KISA) IoT Security Certification Service (IoT-SAP) PH-1 A function to inactivate unnecessary external interfaces and control access as necessary must be provided. 3 View
253 800 Minimise exposed attack surfaces Korea Internet & Security Agency (KISA) IoT Security Certification Service (IoT-SAP) PL3-1 Unnecessary services must be eliminated or inactivated. 3 View
254 799 Minimise exposed attack surfaces Korea Internet & Security Agency (KISA) IoT Security Certification Service (IoT-SAP) PL1-1 Secure coding must be applied so as to eliminate any security weakness and vulnerabilities. 3 View
255 798 Minimise exposed attack surfaces Korea Internet & Security Agency (KISA) IoT Security Certification Service (IoT-SAP) AU1-6 The principle of minimum authority must be applied to all user accounts. 3 View
256 797 Minimise exposed attack surfaces ioXt Alliance The ioXt Security Pledge 2. Secured interfaces All product interfaces shall be appropriately secured by the manufacturer. 3 View
257 796 Minimise exposed attack surfaces IoT Security Initiative Security Design Best Practices Shed technology attack surface whenever and wherever possible in design and development. 1 View
258 795 Minimise exposed attack surfaces IoT Security Initiative Security Design Best Practices Protect the system enclosure and electronics from physical access, probing, and attack. 1 View
259 794 Minimise exposed attack surfaces IoT Security Initiative Security Design Best Practices Conduct security/vulnerability testing on both software code and finished systems. 1 View
260 793 Minimise exposed attack surfaces IoT Security Initiative Security Design Best Practices Validate system security approach and implementation throughout the SDLC. 1 View
261 792 Minimise exposed attack surfaces IoT Security Initiative Security Design Best Practices Consider restricting or tightly controlling access to system components, firmware, and technical data for critical systems. 1 View
262 791 Minimise exposed attack surfaces IoT Security Initiative Security Design Best Practices Run as much system code as possible at the lowest privilege/permission level possible; and as little as you can in highest privilege/permission level. 1 View
263 790 Minimise exposed attack surfaces IoT Security Initiative Security Design Best Practices Compartmentalize communication IO in system design wherever possible; and run these services at least-privilege levels. 1 View
264 789 Minimise exposed attack surfaces IoT Security Initiative Security Design Best Practices Deploy systems and services based on a least-privilege model. 1 View
265 788 Minimise exposed attack surfaces IoT Security Initiative Security Design Best Practices Implement and operate only the system services that are necessary for the function of the system/solution. 1 View
266 787 Minimise exposed attack surfaces IoT Security Initiative Security Design Best Practices Expect software vulnerabilities & validate secure coding using automated & manuals means. 1 View
267 786 Minimise exposed attack surfaces IoT Security Foundation IoT Security Compliance Framework 2.0 2.4.15.1 The configuration of the device and any related web services is tamper resistant i.e. sensitive configuration parameters should only be changeable by authorised people (evidence should list the parameters and who is authorised to change). 3 View
268 785 Minimise exposed attack surfaces IoT Security Foundation IoT Security Compliance Framework 2.0 2.4.14.1 The product has the entire production test and calibration software used during manufacture erased or removed or secured before the product is dispatched from the factory. This is to prevent alteration of the product post manufacture when using authorised production software, for example hacking of the RF characteristics for greater RF ERP. Where such functionality is required in a service centre, it shall be erased or removed upon completion of any servicing activities. 3 View
269 784 Minimise exposed attack surfaces IoT Security Foundation IoT Security Compliance Framework 2.0 2.4.13.31 Product-related cloud services are designed using a defence-in-depth architecture consisting of Virtual Private Clouds (VPCs), firewalled access, and cloud-based monitoring. 3 View
270 783 Minimise exposed attack surfaces IoT Security Foundation IoT Security Compliance Framework 2.0 2.4.13.30 Product-related cloud service databases restrict read/write access to only authorized individuals, devices and services. 3 View
271 782 Minimise exposed attack surfaces IoT Security Foundation IoT Security Compliance Framework 2.0 2.4.13.25 Where device identity and/or configuration registries (e.g. thing shadows) are implemented within a cloud service, the registries are configured to restrict access to only authorised administrators. 3 View
272 781 Minimise exposed attack surfaces IoT Security Foundation IoT Security Compliance Framework 2.0 2.4.13.18 All the related servers and network elements prevent anonymous/guest access except for read only access to public information. 3 View
273 780 Minimise exposed attack surfaces IoT Security Foundation IoT Security Compliance Framework 2.0 2.4.13.8 The related servers have unused IP ports disabled. 3 View
274 779 Minimise exposed attack surfaces IoT Security Foundation IoT Security Compliance Framework 2.0 2.4.13.5 The Product Manufacturer or Service Provider has a process to monitor the relevant security advisories to ensure all the product related web servers use protocols with no publicly known weaknesses. 3 View
275 778 Minimise exposed attack surfaces IoT Security Foundation IoT Security Compliance Framework 2.0 2.4.13.3 All product related web servers have their webserver HTTP trace and trace methods disabled. 3 View
276 777 Minimise exposed attack surfaces IoT Security Foundation IoT Security Compliance Framework 2.0 2.4.13.2 Any product related web servers have their webserver identification options (e.g. Apache or Linux) switched off. 3 View
277 776 Minimise exposed attack surfaces IoT Security Foundation IoT Security Compliance Framework 2.0 2.4.11.8 Secure administration interfaces: it is important that configuration management functionality is accessible only by authorised operators and administrators. Enforce strong authentication over administration interfaces, for example, by using certificates. 3