Evaluating an IoT security model against industry baselines - Embedded.com

Evaluating an IoT security model against industry baselines


Building a house that is strong enough to withstand the test of time requires well-defined codes, specifications based on rigorous testing, and thorough certification.  Building a secure IoT device is no different.  As a part of Open Connectivity Foundation (OCF), engineers from over 450 companies around the world have been collaborating on the trifecta of specification, certification, and open source reference architecture that is required to build secure IoT devices.

(Source: Max Pixels/Creative Commons Zero – CC0)

The word security is thrown around a lot, however, what does it actually mean in the context of IoT devices?  When we talk of security within OCF, we could mention the NIST approved cryptography algorithms and key lengths mandated to be used by every OCF device providing strong identity, encryption, and confidentiality for all device traffic. Or, we could delve into how proper authentication and authorization is an integral and mandatory part of every connection to and from an OCF device once it is on the user’s network.

These are all valid hallmarks of a well implemented security model. However, with security, while it is true that the devil is in the details, it is also true that perspective is a panorama.  The OCF security model cannot adequately be measured unless we can measure it against a bigger picture.   That bigger picture comes in the form of several IoT security baselines developed recently by government and industry organizations.  These baselines give manufacturers, consumers, and the industry as a whole, compelling tools with which to measure and provide external validation of IoT security models and specifications.

For additional details on the OCF security architecture, read this article.
For a guide on getting started building secure devices without writing a line of code, check out this article.

As applied to the OCF specification, these baselines become even more impactful because every mandatory device requirement in OCF has a corresponding certification test (code that verifies that a device meets the specification).  In cases where there is no way to test a particular requirement, the manufacturer must attest that they meet the criteria established in the specification. What this means is that for almost every match between a security baseline capability and the OCF specification there is a corresponding certification (or attestation) test that must be passed by every certified OCF device.

We believe that this linkage of industry and governmental requirements provides a powerful testament to the completeness of the OCF security model. That is why OCF’s Security Oversight Working Group has directed their efforts to mapping the OCF specification across five influential IoT baselines:

  • NIST 8259: National Institute of Standards and Technology NISTR 8259 consists of six main requirements with a total of 22 sub-requirements.  NISTR 8259 is focused specifically on IoT devices and does not layout guidelines for service providers and cloud applications.
  • CTA-C2: The Consumer Technology Association’s “Convene the Conveners” (CTA-C2) consensus on IoT device security is designed to bring together many vertical interests within the IoT market. It consists of ten baseline device capabilities, three baseline device lifecycle capabilities and several additional requirements to be phased in over time.
  • ENISA: European Union Agency for Cybersecurity Baseline Security Recommendations for IoT consists of 15 main requirements with 57 sub-requirements.
  • UK: Code of Practice for Consumer IoT Security from the UK’s Department for Digital, Culture, Media and Sport lays out 13 requirements for IoT devices.
  • ETSI: European Telecommunications Standards Institute has a Cyber Security for Consumer Internet of Things Baseline Requirements that lists 14 main requirements with 67 sub-requirements.  ETSI also lists data protection provisions.

To derive a mapping that would be consistent across all of the baselines we needed to derive three criteria for determining if OCF met each baseline requirement, and if it did not, why? These three criteria include:

  • Met: There is one or more clauses in the OCF specification that meets the baseline requirement.
  • Unmet: Not Applicable: There is no clause in the OCF specification that meets the baseline requirement, but the requirement is out of scope for a device centric specification, or the requirement is implementation/vendor specific.   Examples of out of scope include user data protections in the cloud being both out of scope for a device specification and vendor specific.
  • Unmet: Not Implemented: There is not a clause in the OCF specification that meets the baseline requirement, however the requirement is in scope.

Figure 1 presents the mapping of the OCF specification to the five influential IoT security baselines using these criteria.

Figure 1: Mapping the OCF specification across five influential IoT baselines. (Source: OCF)

For a full searchable mapping of the OCF specification to each of the baselines, visit OCF’s security overview page.

Additional resources

IoT device security: A path to standardization
How to secure IoT connectivity and onboarding without writing code

Kyle Haefner is a senior security engineer at CableLabs and the Chair of the Open Connectivity Security Oversight Work Group. He is also a Ph.D. candidate at Colorado State University where his research focuses on IoT behavioral analysis.


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.