Last updated at Wed, 27 Dec 2023 20:56:45 GMT
I have heard the topic of IoT security certification come up many times over the past several years and often pondered what this would look like, whether it’s even possible to do correctly, and, of course, what “correctly” even means as it applies to IoT.
Between Consumer Reports’ digital standards and Underwriter Laboratories’ IoT certification, we are seeing more and more efforts put in place to form some third-party certification standards and structure. Government officials have also proposed certification programs, such as Sen. Ed Markey’s Cyber Shield Act, and numerous agencies have also published standards and guidelines for IoT security.
As internet-connected devices continue to rapidly evolve, it remains to be seen whether these IoT security certifications will reflect the actual level of device security post-deployment and whether the certifications will make a significant difference in the marketplace.
To expand on these efforts, the Cellular Telecommunications Industry Association (CTIA) recently announced a new cybersecurity certification program for cellular- and Wi-Fi-connected IoT devices. The wireless industry trade association also released the associated documentation, which makes it easier for security professionals to review the standards for their certification.
The following is a high-level review of this certification program:
IoT Security Certification: What does it take to qualify?
In order to qualify for this IoT certification program, the IoT device in question must utilize LTE communications and/or Wi-Fi communications. Also, if used by the product, both of these communication methods must also be certified by the Wi-Fi Alliance (if using Wi-Fi) and/or certified by PTCRB or GCF (if using LTE). The purpose of this is to ensure the communication method used meets industry standards first.
There are currently three defined categories in the CTIA certification program. Here is a high-level overview of those categories:
Category 1
- Terms of services and privacy policies (must address end of security support)
- Password management
- Authentication
- Access controls
- Patch management
- Software upgrades
Category 2 (Includes Category 1 criteria)
- Audit log
- Encryption of data in transit
- Multi-factor authentication
- Remote deactivation
- Secure boot
- Threat monitoring
- IoT device identity
Category 3 (Includes Category 1 and Category 2 criteria)
- Encryption of data at rest
- Digital signature generation and validation
- Tamper evidence
- Design-in features
Each advancing category of certification is built upon the previous one(s), which means you must pass all requirements in Category 1 to be reviewed and tested under Category 2’s standards.
My takeaways
So, what do I like about this? Well, for one, it creates a simple baseline certification. The questions asked are nearly identical to the ones I advise businesses and industries to ask prior to purchasing and deploying IoT technology. I am pleased to see some of the ideas from the NTIA Multistakeholder process I recently participated in being leveraged, such as addressing the expected lifetime of security support.
I think this can be a great start for a certification program. It is open, measurable, and can hopefully be built upon moving forward. But I must also point out that this is a baseline certification, even at the Category 3 level. I personally do not believe it guarantees a secure product—rather, it only ensures that the items tested for are valid at the point of testing for these specific security features.
What did I notice that could use improvement? While looking at these certification categories in detail, I believe most consumer-based IoT goods on the market today will not meet the full requirements for any category above Category 1. I say this because the requirements in Category 2—such as the audit log, threat detection and monitoring, and remote deactivation—are typically found on more enterprise solutions, rather than consumer-grade technology. However, this certification framework does not account for device type or expected user, just the security features present.
With that said, I would love to see some of the items in Category 2—such as encryption of data in transit and secure boot—validated as part of the certification process for consumer-grade IoT products. However, this is less likely if they can’t pass every part of the Category 2 requirements. Because the features are bundled in each category, a product must meet every feature in the bundle to get the category certification. By moving encryption to Category 2 and Category 3, there may be less incentive to include encryption in a consumer-grade product if the product is not going to meet the other Category 2 features and attain the Category 2 certification.
Perhaps the solution is to ensure that each security feature is incentivized, even if a full category certification is unavailable. For example, a consumer device that meets Category 1 certification and also has encryption at rest and in transit (but not multi-factor authentication) could perhaps receive a Cat. 1 + Crypto certification.
If you have not reviewed this certification program, I recommend you download it, give it a read, and form your own opinion. I went into this with eyes wide open, knowing that it is not possible to create a 100% perfect solution that will solve all problems. For the most part, I liked what I saw and see it as a great starting point—CTIA should be commended for its effort so far. As long as we don’t make certification programs like this our only test of security, then I think such programs can be used to add true value.
