Solving IoT device security at scale through standards

Edge Compute Node protection profile (ECN PP)—now available—guides you to engineer, claim, evaluate, and consume device security for IoT.

Internet of Things (IoT) solution builders these days are more likely to deploy IoT solutions with unsecured devices because they cannot verify device security claims from device makers.

Solution builders could create secured devices themselves, however they don’t because they either lack domain expertise or simply prefer to buy devices off-the-shelf. Device makers possess the requisite expertise to secure devices, but lack ability to convey details.

For example, language constructs such as 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—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 IoT globally connect solutions, supply chains, and interests irrespective of company, geography, or governmental affiliations, effectively solving the stalemate also requires global openness. We undertook this challenge and can report significant progress.

We’re happy to share general availability of the Edge Compute Node protection profile (NSCIB-CC-0112146-CR or simply ECN PP), a Common Criteria (ISO 15408) standard, which guides you 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.

 

Figure 1. Starting now, confidently know and acquire only secured devices as baseline to a holistically secured IoT deployment.

At Microsoft, we created and drove development of ECN PP, however our efforts were immensely amplified by the following partners contributing diverse expertise and experience:

Figure 2. 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. Here is what one of our partners had to say:

“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, Prove & Run

Device makers and solution builders can now freely access ECN PP from the Common Criteria official portal, and can later view the list of ECN PP certified devices on the same portal. We’re excited to see that 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 their 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 chooses 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 subcomponent which would be the minimum baseline as Figure 1 above illustrates.

Sizing the solution right—device security promise

A major goal in security is to balance efficacy with cost, otherwise unintended consequences result. Choose cheaper and risk efficacy or spend too much and risk security budget cuts. For IoT devices, secured silicon (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 which currently offer a standard promise, secure element promise, and secure enclave promise for sizing.

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 (SMM) by the Industrial Internet Consortium (ICC) 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, shows how much resistance one can expect from the secure silicon against physical and environmental tampering. This 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 goal, grouped under convenient categories, and accommodates device security promise customization.

Figure 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, however we envision using it to build more. To start, 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.

Figure 5. One setup for real-time attestations. We invite lab and device partners for collaboration.

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 positive outcome 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’re already seeing strong interest and real engagements illustrated below in figure 6:

Figure 6. Real engagement highlight showing device maker, Scalys, following ECN PP 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 our partners who have joined us on this journey already to secure IoT for all.  See the following resources to learn how you can engage:

• Access Edge Compute Node protection profile now from the Common Criterial official 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.

Source: Azure Blog Feed