How to Enforce IoT Security Standards and Compliance
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
● 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.
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.
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.
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!
GHIDRA may be the preferred tool of choice for analyzing RTOS firmware images. We will demonstrate identification of a published vulnerability as a case study.
Backdoored firmware found in the supply chain of video surveillance chips from HiSilicon (a subsidiary of Huawei) allows remote access via Telnet.