How to Enforce IoT Security Standards and Compliance

by Jun 16, 2020

National and International IoT Standards

We are all aware of the persistent insecurity of IoT devices – for consumers, enterprises and critical infrastructure.

To address the threat, a wide variety of standards are in various stages of development to enforce cyber hygiene by device manufacturers and allow purchasers to identify secure products

Examples include:

OWASP IoT Top 10
UL 2900
● US: NIST 8259 IoT Baseline, State of California SB-327 IoT privacy standards
● Europe: ENISA Baseline Security Recommendations, UK Code of Practice for Consumer IoT Security

 

Industry Specific IoT Standards

Individual industry sectors have their own security standards as well, for example:

● Telecommunications (ETSI Cyber Security for Consumer IoT, BITAG IoT Security Recommendations, CTIA IoT Security Certification)
● Industrial Control Systems (ISA/IEC 62443)
● Automotive (ISO/SAE 21434)
● Energy (NERC CIP-10)

Some of these standards are having an impact by depriving market access or imposing large fines to vendors who ship products with poor security.

And more are coming.

IoT Security Standards

 

Failure to Follow IoT Standards COULD SOON Cost Money

In March 2020 the US Cyberspace Solarium Commission recommended that device manufacturers be held liable for incidents that exploit known and unpatched vulnerabilities.

With all of these certification standards and compliance regulations, conducting product cybersecurity assessments quickly becomes very complicated and expensive.

 

IoT Security Standards & Compliance Checking

Device manufacturers need to integrate compliance checking into their development process, and get visibility into the security of 3rd party components from their supply chain.

Device users, especially in critical infrastructure sectors, are required to conduct product security and vulnerability assessments to determine whether a new product or firmware release meets their standards before putting it on their network.

To help address this challenge, the Spring ‘20 release of the Centrifuge Platform introduces the ability to conduct and generate security compliance reports against firmware.

Here’s how it works.

1. Define a security policy for your organization or for your specific product line

2. Upload the firmware into the Centrifuge Platform for analysis

3. Review the report to quickly determine whether the firmware passes or fails

Detailed reasons are presented as to why a policy failed, which helps communicate remediation steps to stakeholders.

Centrifuge Security Policy

Security policies can be mapped directly to emerging IoT security best practices and certification standards such as the OWASP IoT Top 10. The Centrifuge Security Policy Engine can map to the recommendations, such as hardcoded passwords (I1), use of outdated components (I5) and insecure network services (I2).

While some items cannot be determined completely through firmware analysis (i.e., insecure cloud or mobile applications), the Centrifuge Platform can now quickly assess firmware compliance with various standards.

The Spring ‘20 initial release is meant for integration into automated development or security assessment workflows via the Centrifuge command line.

Recent Posts
How to Compare Two Different Binary Files

How to Compare Two Different Binary Files

One of our favorite new capabilities in the Centrifuge Spring ‘20 release is Firmware Differencing. This is how to compare two binary files quickly and efficiently for Linux, QNX, and VxWorks. But that’s not all it compares!