Solving IoT device security at scale through standards
Published Sep 21 2020 12:00 PM 3,354 Views
Microsoft

Companies building Internet of Things (IoT) solutions today are likely to deploy IoT applications that use unsecured devices, mainly because they cannot verify the security claims from device manufacturers.

 

Solution builders could create secured devices themselves. They tend not to because they either lack domain expertise, or simply prefer to buy devices off-the-shelf. Device makers, on the other hand, possess the requisite expertise to secure devices but lack the ability to convey details. For example, language constructs such as for conveying computation, storage, and power profiles of an Industrial PC (IPC), are simply not available for security.  Device makers therefore see no motivation to invest in securing devices if they can’t claim the value and hence the current stalemate. Our studies and observations show this stalemate exists for two reasons:

 

  • Lack of standards guiding how to holistically engineer and claim device security.
  • Lack of standards guiding how to consume and verify device security claims.

 

Given how IoT globally connects solutions, supply chains, and interests irrespective of company, geography, or governmental affiliations, effectively solving the stalemate requires global openness as well. 

 

We’re happy to announce the Edge Compute Node protection profile (ECN PP), a Common Criteria (ISO 15408) standard that will guide how to engineer, claim, evaluate, and consume security for IoT devices.  We build on Common Criteria for transparency, cross-industry practice, global recognition arrangements, and global availability of licensed laboratories.  Edge Compute Node protection profile, officially NSCIB-CC-0112146-CR, is in final step of certification.

 

We created and drove development of ECN PP here at Microsoft but our efforts were immensely amplified by the following partners contributing diverse expertise and experience, and for whom we’re very grateful. 

 

Figure 1: We recognize these collaborators with gratitude for amplifying our efforts with their diverse expertise.Figure 1: We recognize these collaborators with gratitude for amplifying our efforts with their diverse expertise.

 

We’re excited by this development and so are our partners:

 

“ProvenRun’s mission is to help its customers resolve the security challenges linked to the large-scale deployment of connected devices. We are very proud to have contributed our expertise into this mission to enable industry motions that help ensure all IoT deployments are secured-by-design”,  Dominique Bolignano, CEO and founder, ProvenRun.

When ready, device makers and solution builders can freely access ECN PP from the Common Criteria portal, and later view list of ECN PP certified devices.  We’re excited to see how ECN PP co-development partners are already putting it into use as we illustrate one real example at the end of this article. Device makers of products like Azure IoT Edge can now holistically secure devices, objectively claim security, and be assured of differentiated visibility on Azure device catalog in addition to the Common Criteria portal.  We envision other IoT solution providers building custom experiences with ECN PP on respective platforms.  For us, ECN PP is only the beginning of an exciting journey in which we invite you to join us in making it our common journey towards a unified goal.

 

How we see security in IoT

Our vision for security in IoT is a world in which every IoT ecosystem stakeholder choices and actions contributes to overall security of IoT where consumers and benefactors are simply secured by default.  To a solution builder as an example, this means building with components that have been certified to deliver all security and compliance requirements for the target solution.   We achieve this vision by standardizing a baseline and then evolve this baseline with maturity.  Given afore described stalemate between the IoT solution builder and device maker, it stands to reason for the IoT device, and not the security subcomponents, to be the current minimum baseline.

 

Figure 2: The IoT device as the practical minimum baseline to standardize on security.Figure 2: The IoT device as the practical minimum baseline to standardize on security.

 

Sizing the solution right – device security promise

A major goal in security is to balance efficacy with cost otherwise unintended consequences result.   Go cheap and risk efficacy or spend too much and risk security budget cuts.  For IoT devices, secured silicon (aka hardware security module or simply HSM) is often the last defense to deliver resistance against tampering from malicious physical access.  Secure silicon together with associated engineering and operating costs is also the biggest cost driver.  A need therefore arises to appropriately size secure silicon investments for the IoT deployment risk profile.   We address this need by providing a useful tool to judge the coverage expected of the secure silicon, a tool we call device security promise, that currently offer standard promise, secure element promise, and secure enclave promise for sizing.

 

Figure 3: Device security promise for IoT devices.Figure 3: Device security promise for IoT devices.

 

If you wondered how to assess the IoT deployment risk then you are in luck.  The IoT Security Maturity Model by the Industrial Internet Consortium delivers excellent tools and guidance for exactly this purpose. You can also learn more here about the role of secure silicon in securing IoT.

 

It is worthwhile to note device security promise only conveys the scope of secure silicon isolation.  Robustness in protection, for example how much resistance can one expect from the secure silicon against physical and environmental tampering, derives from depth in secure silicon security engineering and qualifiable through standards such as the National Institute of Standards and Technology’s (NIST) Federal Information Processing Standard 140-2 (FIPS 140-2) and Platform Security Architecture certification (PSA Certified™). ECN PP captures and reports compliances to standards addressing robustness for a holistic view of the device security posture.  The approach taken by ECN PP is equally important.

 

Measurable goals over prescriptions

ECN PP defines measurable security goals instead of component prescription.  This approach invites and engages unique talents and expertise of device makers in achieving these goals for efficacy while simultaneously garnering product differentiation.  We avoid prescriptions to preclude blind compliance with no stake in efficacy, which brings us back to the problem we set out to solve.  The result is a modular protection profile that presents a comprehensive security goals grouped under convenient categories and accommodates device security promise customization.

 

Figure 4: ECN PP modularly structured for device security promise customizationFigure 4: ECN PP modularly structured for device security promise customization

 

Taking device security certification to the next level with programmatic real-time attestations

ECN PP on its own provides the tools that help enable secured IoT deployments through standards for collaboration and global transparency, but we envision using it to build more.  To start with, while Common Criterial portal shall remain authoritative listing for security ECN PP compliant devices, device makers with ECN PP compliant devices certified for Azure will merit product targeted recognition within our IoT device catalog.  We’re excited for this ability to recognize our device partner commitment to security.  We’re equally excited about our current engagements to build on ECN PP and deliver programmatic real-time device security attestations.

kartben_0-1600710678038.png

Beyond visibility into overall deployment security posture, programmatic workflows with real-time security attestations will empower solution builders to target workloads only to devices that meet certain security posture for example, they can target workloads with confidential or privacy content only to secure enclave promise devices.  Another pleasant upshot are the signals these workflows will generate to device makers for the types of devices in demand based on device security promise.

 

While this work is just being announced, we already see strong interest and real engagements such as follows:

kartben_0-1600710744202.png

This is an example of a device maker, Scalys, following ECN guidance to select Arm TrustZone® based NXP Layerscape® LS1012A to build a robust secure enclave promise device, and engaging UL to setup for certification. A solution builder will discover Scalys certified device from Common Criteria portal, and build solution they can later attest the device’s security real-time.

 

What’s next

We thank all the partners that have joined us already on this journey to secure IoT for all and invite more.  Engage now as follows:

  • Access Edge Compute Node protection profile, NSCIB-CC-0112146-CR, coming very soon to Common Criterial portal.
  • Device makers - engineer device security to ECN PP, engage any Common Criterial licensed lab for certification and attestation setup, and view Common Criterial portal for licensed devices (allow time for engineering and certification of early devices).
  • Solution builders – demand ECN PP compliant devices for security assurance.
  • Common Criterial licensed labs – contact us to setup for device attestation.
  • Technology partners - join us to evolve ECN PP.

 

Version history
Last update:
‎Sep 21 2020 10:55 AM
Updated by: