As IoT applications become mission critical, security is paramount. By their very nature, IoT ecosystems are vulnerable to security threats at multiple levels. Faced with a constantly evolving landscape, an agile approach to security is required by developers of IoT ecosystems, in order to respond rapidly to emerging threats. Both device manufacturers and ecosystem developers must have simple, scalable and sustainable IoT security strategies in place to achieve short- and long-term business objectives.

IoT security is undoubtedly a complex field requiring specialist security expertise. Organizations must decide whether to retain this scarce resource, with the associated investments in ongoing training, or to partner with external organizations that can provide the required support throughout the development cycle.

Security and Quality Assurance

Existing Total Quality Management (TQM) processes in the software industry already address security issues and the Plan, Do, Check, Act process (Figure 1) embodied in the ISO-27001 information security standard is well understood as a secure development methodology.

 

 

Figure 1: The Plan, Do, Act, Check (PDCA) Development Process.

Developers of IoT ecosystems must also demonstrate compliance with relevant regulations and standards through vetting by independent public bodies. Relevant standards include the Common Criteria for Information Technology Security Evaluation (ISO/IEC 15408); the US’ Federal Information Processing Standards Publication (FIPS); and the Baseline Security Certification (CSPN), operated by ANSSI, the national security agency of France. Within the EU, products, processes, and services are certified through the European Cybersecurity Certification process, which is owned by the European Network Information Security Agency. This process is based upon the success of CSPN and certificates…once issued, they are recognized throughout the Union.

As well as negotiating the complexities of the PDCA process, organizations developing secure IoT ecosystems must therefore also understand how and when to interact with the relevant standards bodies and vetting agencies.

The PDCA Process

PLAN

As with any project, developing a secure IoT ecosystem begins with a robust plan which should ensure that security issues are addressed as early as possible in the development cycle. The plan should identify business risks and high priority assets requiring protection and should also include a rigorous threat assessment and elaboration of the security measures required for effective risk mitigation. Threat modelling and assessment is a key security practice and the STRIDE methodology (Figure 2), developed by Microsoft security engineers, is a commonly used tool for this phase.

Figure 2: STRIDE Risks and Threats Assessment.

The output of this assessment is a document which forms the basis of the client’s integrated risk management approach and is a key enabler of future compliance and formal certification.

DO: Design the IoT Security Architecture

The threat assessment findings must now be embodied in the design of the IoT solution’s security architecture. The scope of this design covers both hardware and software and, to ensure resilience to evolving cyber threats, designers must make certain that:

• Any IoT device has a unique ID which cannot be cloned, laying the foundation for all other security functions. This Root of Trust (RoT) functionality enables all parties to trust the identity, authentication, communication, and data coming from the device. The RoT also provides the hardware and software cryptographic capabilities required to enable trusted functions and API layers enable external applications to access these capabilities.
• CPU, memory, and connectivity can’t be used for non-designated tasks, limiting the threat from hacker activities.
• Privacy, confidentiality, and regulatory compliance are ensured by protecting the integrity of all data, whether static or in motion.
• Decisions made using data from an IoT ecosystem are executed in a secure environment, safe from tampering and intellectual property theft.
•  Any commands sent to an IoT device (e.g. ‘inject insulin’, ‘open/close valve’, ‘apply brakes’ etc.) are validated as coming from a legitimate source.

This phase of the project is key to establishing an effective IoT security architecture and requires the use of a highly trained, expert resource. This resource is notoriously scarce within the industry and retention may be further complicated by the cyclical nature of product development: Security design is typically done once and then reused for an entire product family, meaning that in-house security experts may not be continuously utilized. It may therefore make sense for many organizations to consider working with external partners, who cannot only provide the required security design expertise but can also offer advice and guidance throughout the end-to-end PDCA process.

Upon completion of the DO phase of the PDCA process, the secure architecture design is ready for penetration testing.

CHECK: Defend, Attack, Score

To ensure that the device meets the security requirements of its target market, it must be tested for compliance or formal certification by an independent body, such as CSPN. Testing by an independent organization avoids the conflicts of interest that may exist with business-backed bodies and standards such as Common Criteria, ensuring the objectivity of testing. Assessing an IoT device’s security level requires the use of accepted references and methodologies to assess its robustness against formally identified threats. This evaluation can be conducted using either a quantitative or a qualitative approach.

Attack scoring is a widely used quantitative method where the Evaluation Assurance Level (EAL) is refined with a score determined through a vetting process, conducted by an independent security laboratory. The two commonly applied scoring mechanisms are either the Joint Interpretation Library methodology, used by CSPN, or the Common Vulnerability Scoring System, managed by FIRST (Forum of Incident Response and Security teams).

Qualitative evaluations, also conducted by independent security laboratories, test for security gaps within the device, which would enable the success of high-probability, high-impact attacks. The degree of evaluation for this methodology is based on the level of expertise and the complexity of the tools that would be required to mount a realistic attack. This approach establishes a security or confidence level in the device, with the assigned level being reached when testing activities fail to reveal a gap for the defined attack.

A qualitative baseline evaluation is sufficient for most IoT products and this evaluation can be further simplified for products which are built on devices that have already been through a security evaluation process, such as u-blox’s range of cellular IoT modules. Certified modules such as these will have undergone extensive evaluations, simulating typical paths of attack and testing the embedded security of the devices against attacks including fault injections and side-channel analysis. By integrating modules which have been tested to this level, developers gain the assurance that an attacker with physical access to the device will not be able to defeat the security countermeasures and that cryptographic algorithms, private keys and other security functionality are secure.

ACT

Following the planning, design and evaluation stages, the IoT device security must be deployed, scaled and sustained throughout the device’s lifecycle.

Although software security implementations can suffice for low-threat, low-business-value situations, devices used in high-value, high-exposure applications require a hardware RoT, provisioned at a trusted location, during the production run. The security challenges of large-scale IoT ecosystem deployments must also demand the inclusion of features such as zero-touch provisioning, secure cloud connectivity and power and bandwidth efficient key management.

Reducing the in-life exposure to security threats requires the collection and monitoring of large quantities of both internally and externally sourced data. Although this can be a demanding task, it is critical to ensure the timely detection and remediation of threats. Organizations without the necessary in-house resource should seriously consider working with a trusted partner on this activity.

Engaging with External Support Throughout the Security Journey

Many specialist security organizations, such as the u-blox and Kudelski partnership, can provide expert security capabilities to support you throughout the PDCA workflow, irrespective of where you may be in the development process (Figure 3).

Figure 3: The IoT Security Lab Journey.

Typically, expert security analysis, advice and design services may include assessment and evaluation of chip-level, PCB-level and software security through a tailored vulnerability and threat analysis, end-to-end security architecture consulting and comprehensive pre-release testing.

The Security Solution

As described above, the security process can be simplified for solutions which are based upon certified modules such as the u-blox cellular range. These modules integrate the Kudelski IoT security platform, which creates a chain of trust linking devices, data, IoT platforms and applications, enabling users to manage all key IoT assets using simple APIs. The platform is comprised of three elements – a software or hardware RoT, a device-based security client and a cloud, or customer-premise based, security server. The pre-integrated components include features which enable the implementation of secure device designs and data for IoT applications. Users of the platform can create and operate a wide range of digital and physical assets and ensure that the security protection adapts to future threats.

Designing an effective IoT security architecture is an essential but complex process requiring the use of specialist expertise. The PDCA process is a well-established methodology which incorporates the necessary security testing and certification steps and, when properly applied, ensures the implementation of a robust IoT security architecture. Organizations can choose to retain this scarce resource or engage with external providers, depending upon the specifics of their product development cycles.

Author Bio

Eric Heiser joined the Product Center Cellular at u-blox AG in 2016. Prior to this position, he was Division Vice President & GM, Strategic Sales & Corporate Planning at Kyocera Communications Inc. for 8 years. Eric Heiser holds an MBA from Marriott School of Business, BYU and a B.S. in Electrical Engineering of University of Missouri, Rolla.

The IoT Security Lab is a consulting service offered by u-blox in partnership with the Kudelski Group, which has more than 30 years’ experience of protecting business assets in high-value ecosystems. For more information visit here.