Mozilla's Minimum Security Guidelines
Mozilla outlines the need for security policies essential to maximize the protection of IoT devices and recommendations for manufacturers to enhance transparency and communication.
Mozilla’s minimum security guidelines are unique as they take into account all the life-cycle (long-term sustainability), security, privacy as well as interoperability issues while others focus mostly only on one at a time. Secondly, it addresses the entire IoT ecosystem including sensors, devices, mobile apps, back-end services rather than focusing on just the devices.
Serving as a risk assessment guide for developers, the goal of Mozilla guidelines is to highlight the devices which meet these standards to help consumers make informed decisions
Five Minimum Security Standards-
Encrypted Communications- The devices and applications should support security best practices and strong cryptography protocols, all the personal data in transit and in storage must be encrypted. The IoT support websites must also fully encrypt the user session by including best practices like HTTPS and HSTS (aka AOSSL) along with back-end services authentication. They must also implement server configurations, regular monitoring and improvement of site security to reduce the impact of vulnerabilities. Semi-annual penetration tests are also recommended.
Security Updates- The product must be capable of receiving automated security-related updates. Automated updates provide users with the ability to approve or reject the updates. A secure automated mechanism must be in place to deliver the updates, patches and revisions seamlessly after the vulnerability disclosure. Also, the vendor must disclose what actions will be required from the consumer end for correct and timely updates and that the updates are verified to be coming from a trusted source. Devices should be made available to the customer with current software and on first boot should push automatic updates to address any known critical vulnerabilities.
Vulnerability Management- A coordinated vulnerability disclosure mechanism must be established which includes receiving, tracking and responding promptly to external vulnerability reports from third parties. Vendors must also re mediate design threats and vulnerabilities post product release either through remote updates or through actionable consumer notifications. Crowd-sourcing methods and bug bounty programs must be used by the developers to identify vulnerabilities.
Strong Passwords- The device must include strong authentication by default with the use of secure certificate credentials or single use and unique passwords for administrative access, including having password strength requirements. Authentication credentials shall be salted, encrypted or hashed to help prevent brute force attacks and other abusive login attempts such as automated login bots etc. Providing recovery mechanisms, credential reset mechanism using multi-factor authentication and verification (by, email etc), notifying users of password change, locking/disabling support accounts after several invalid login attempts help protect the device from vulnerability to guessable password attacks.
Privacy Practices- The device must have privacy and support policies that are clear, easily discoverable and readily available for user review prior to the product purchase or activation. Utilization of user-friendly short URLs, QR codes, and prominent placement of policies on product packaging and product website is recommended for companies. Beyond product warranty, duration and end-of-life security and patch support should be communicated to the consumer prior to purchase along with any subscription to an annual support agreement. The vendor must disclose what sensitive information will be collected by the device and how it will be used for its functionality. Ownership, data transfer mechanisms, storage duration, retention policy must be disclosed by the vendor and the users must be able to review and edit privacy preferences including the ability to reset to the “factory default” and, as in line with GDPR, there should be a way to opt-out of such practices. IoT device must request user confirmation when initially pairing/connecting with other devices and services. Also, vendors must take consumers’ affirmative consent before sharing their personal data with the third parties and should provide the ability to delete or make anonymous the stored data on company servers upon loss or discontinuing use of the device.
GSMA IoT Security Guidelines-
GSMA (GSM Association or Global System for Mobile Communications) Guidelines help promote best practices for secure design, development and deployment of IoT products and provide a mechanism to address security challenges and risk assessments.
GSMA recommends the following high-level steps at the early development stages of IoT product/service for mobile network operators worldwide to minimize any privacy risks:
- Determine what user data needs to be collected for the proper functioning of a new IoT offering. The data can be either static such as name and address or dynamic (real-time) such as a user’s location. It is also necessary to decide whether user consent is required to use or collect that data, what will be the means of obtaining consent and how to offer the user options to control their privacy preferences.
- Next step is identifying legal compliance requirements―whether the collected data is personal and subject to data protection laws. Also, whether any privacy-related license conditions are to be fulfilled to process such data.
- After identifying data protection and privacy requirements, the next step is to ensure that data is secured both in storage and during transmission, data flows are clearly set i.e. how data will be used and who it will be shared with and for what purposes. Also, keep appropriate contractual agreements (that include consequences and liabilities if failed to comply) in place with the companies you are sharing data with.
- Conducting a Privacy Impact Assessment (PIA) is becoming common in privacy regulations. It takes into consideration any privacy risks that can be raised for consumers due to possible misuse of their personal information, reducing the associated risks and designing a more effective process for handling individual data.
- After privacy risk assessment, it is required to increase consumers’ awareness about what data they are sharing through their device, the possible dangers, steps to mitigate them as well as allowing them to define their privacy preferences. This helps in building user trust since they become reassured of having more control over their data.
- The IoT product/service may collect data that is not classified as ‘personal’ but when integrated with data from other sources may give information about the user that might have privacy implications on the consumer. This should, therefore, be considered early on. Such implications must also be considered in case the offered product/service is likely to change in the future (e.g. more data collection, data sharing with a new party). Consumers must be informed of any such changes and their consent must be taken along with providing the means to change their privacy preferences and clear redressal process so that user know who to turn to if they suffer from a privacy breach.
NIST Cybersecurity Guidelines
National Institute of Standards and Technology (NIST) promotes awareness of 17 technical concernsthat can affect a user’s level of confidence (trust) in IoT. Most of these trust-related concerns have no current resolution but wherever possible NIST has recommended steps to mitigate them. These guidelines should be of interest to technical staff, managers, policy makers, government, or any other IoT integrator/adopter.
The following IoT trust concerns must be addressed before and after deploying IoT systems:
Scalability- The combinatorial explosion and functionality bloat caused by the inter-connectivity of a large number of things and networks are the trust concerns. This allows connectivity, complexity, energy and bandwidth demands to skyrocket causing difficulty for testing, performance and security. By limiting internet access for a specific network of things, the threat space can be reduced and testing becomes more thorough.
Heterogeneity- Competition in the marketplace causes this trust concern resulting in lower prices but also ‘emergent behaviours’ that create new vulnerabilities as well as impact performance and reliability. Heterogeneity-related vulnerability issues also generate with supply chain applications.
Ownership and Control- Integration of third-party black boxes is of concern, particularly for security and reliability. Black box devices aren’t observable and have no transparency and can contain malicious trojan behaviours. The loss in access to internals functionality limits the trust of the IoT adopters in their systems. Risk assessment such as white-box testing approaches should continue throughout operation and deployment to mitigate risks.
Composability, Interoperability, Integration and Compatibility- Composability trust depends on the working of IoT hardware and software components. Right component selection, security & reliability of the components, specification & architecture of the IoT system itself affects this concern. Further concerns arise if the components cannot work in conjunction without conflict, cannot be swapped as per system requirements, or cannot communicate properly. Therefore proper inspection of each component before the adoption is necessary. To address these issues, it is important to understand the actual behaviour of the “things”, their environment, context, operating time, communication channels and application of architecture principles and risk assessment and mitigation approaches.
Ilities- Ilities are the non-functional requirements that state the level of quality a system should exhibit both for the functional requirements (what a system shall do) and negative requirements(what a system shall not do). The concern is that there are dozens of ilities and most are not easily measured. On top of that, some of the ilities are in technical conflict so a system cannot have high levels of all. Ranking them on basis of importance, level and cost is a challenge for IoT adopters. It is recommended to consider ilities on a case-by-case basis at the beginning of the IoT system’s life cycle.
Synchronization- Being distributed computing systems, IoT devices have numerous computations and events occurring in parallel for which some degree of synchronization is needed. For that to occur a timing mechanism is needed however no such global clock exists resulting in timing anomalies, poor performance and vulnerabilities. Timing being a vital trust component, central timestamping authority for all events would be beneficial.
Measurement- Lack of metrics and measures for the Internet of Things makes it difficult to trust the system or even estimate the amount of testing it should receive. Since IoT is a relatively new set of technologies, scarce availability of these “keystones of trust” is a matter of concern. Static testing eg. code checking for vulnerability detection can be added to the list.
Predictability- The trust issue stems from the inability to assure how the components of the IoT system will perform and interact and whether they will provide the specified resources and functions whenever needed.
Testing and Assurance- Greater interdependencies in the IoT system creates additional testing difficulties/challenges compared to the conventional systems. Most IoT systems are built from black box devices & services that offer no transparency into their internal workings. Also, being highly data-driven, IoT devices need to assure data integrity and resilience to data anomalies. Array generation algorithms, methods based on combinatorics and design of experiments work extremely well in testing complex interactions.
Certification- Certification often causes conflict and is unlikely to offer the required degree of trust because of unacceptable answers to questions such as what will be the criteria for selection and who will perform certification, lifespan of device relative to the time required for its certification, impact on market launch if system gets certification prior to operation etc. A good first recommended step here is to define the type of concerned quality.
Reliability- It will rarely be possible to claim that the IoT system is reliable as it depends on the resilience to handle any anomalous event that the system can experience and the correct knowledge of the context and environment.
Data integrity- The quality of data to and from the IoT system determines whether it is fit-for-purpose. Availability, fidelity, accuracy and confidence against data tampering are the factors that impact the ability to trust data. Data storage is another major concern as leased data can originate from anywhere, be it cloud.
Excessive data- IoT systems are data-driven and their rapidly changing workflow generates and receives huge amounts of data, guaranteeing the integrity of which is a trustworthiness concern.
Performance- The increased computational speed and data generation is a concerning situation. This inhibits auditing transactions as the rate of data generation exceeds the speed of storage. This, in turn, makes correcting computations, failure recovery and real-time forensic analysis harder because of lost data/data anomalies and inability to meet computational deadlines.
Usability- Whether users understand how to use the devices is an important consideration. Limited display size, functionality and parameter control accessibility only via remote means have significant implications over user trust.
Visibility & Discovery- When technologies become so ingrained in the user’s daily life that they become invisible to them manifests a trust concern. For example, using voice response technologywhen you talk to your device, how do you know if it is the only system listening? Discovery trust concern stems from the fact that IoT devices have enabled many new protocol families, causing a vast number of possible interactions that are prone to reliability and security problems.
Security- It is a concern for all ‘things’- network, timing and devices themselves. Sensors and data may be transmitted and accessed by unauthorized parties for malicious intent. Data may be flawed (partially/totally), dropped, tampered with, stolen. Malicious tampering with sensors may cause loss of sensitivity/calibration. Communication channels and data aggregators are also prone to malicious disturbances such as false data feed or inability to execute data. Unique identifiers help partially mitigate this problem by attaching RFID (Radio Frequency identifier) tags to physical primitives. RFID readers distributed at key points throughout the network activates a tag and cause it to broadcast radio waves within the government-reserved bandwidths for RFID usage.
The actual time at which computations are performed or an event in a workflow is generated may also be tampered with by changing the recorded time. Hackers can affect the execution of decision triggers by inducing delays (eg. sticking in a delay() function call).
Conclusion-
The Internet of Things begins with your things—the things that matter most to organizations. IoT can convey amazing value to a business by expanding revenue, decreasing costs, and transforming business. The success of this change to a great extent relies upon customer satisfaction and buyer protection. That implies finding a provider that catalyzes this compliance by understanding business needs and prerequisites, or compliance to security guidelines by providing specialised training to your team with compliance, privacy, security, and transparency as major considerations. Attify has broad involvement with creating IoT Security benefits and specializes in training, ranging from beginner to advanced levels in the domain of IoT & Mobile Security.
