By Wouter Slegers, CEO, TrustCB
On one side, consumers want to be able to trust the security in their devices. On the other side, among technology providers, there seems to be a reality gap: In a recent survey by PSA Certified, 87 percent of respondents said they’re satisfied with the quality of IoT security implementations within their company. However, 84 percent of the companies that have adopted an IoT strategy have reported8 a security breach. Clearly the self-developed, self-assessed security implementations are not providing what everyone – except for cybercriminals – wants: trusted security in their digital devices. The trick is charting the right course to ensure that happens.
Governments and regulatory bodies, reacting to the headlines and a perceived lack of industry progress, are increasingly enacting standards, laws and rules outlining how security needs to improve. Companies, on the other hand, tend to want to ensure their products will be easily certified in components, enabling reuse of certification in the interests of time, efficiency, and money. This combination of forces demonstrates what should be the path forward: third-party certification and attestation to do security evaluation once and reuse it efficiently.
Certification and attestation is the two-step dance that ensures that, at the hardware level, devices are what they say they are, and going up the software stack, at the product level, validates they are still providing the expected level of security. It enables longevity in the security of connected devices, and an audit trail to ensure best practices are being followed in the supply chain and in the usage.
As the world looks to well-known laboratories and certification authorities to certify the security robustness of countless consumer devices, so too is it beginning to look to our industry for similarly making development, evaluation and certification
fast, easy, and predictable in a modular fashion. The good news is the solution development has been underway for a long time; the challenge is building on the momentum to ensure that industry properly self-regulates and avoids overly heavy governmental intervention.
One-two punch
The two-step approach to enabling more trusted devices is split between hardware and software platforms (the chips and the OS), and making these into end products (the doorbells, voice assistants, and such).
The first step, certification of the platforms, is a validation against well-defined requirements that the platform provides the secure functionality as advertised. Developing such secure functionality and evaluating its robustness against serious attackers is an important, niche skill. But once that functionality is known to be secure, it is easy to use that functionality and make a secure product out of it.
This makes the second step easy: The product developer will rely on the secure platform, and focus on the distinctive functionality to make the product. Thus, certification makes it easy to ensure that your digital doorbell or voice assistant is secure and attestation shows your supply chain security credentials are in order.
Police thy self?
Many companies (62 percent in that PSA Certified report cited earlier) have relied on self-certification to ensure for their customers that their products are trustworthy.
This has the benefit of being controllable by the company and is usually expedient. But this approach is not robust enough (especially if the threat model isn’t well-rounded, or in many cases is non-existent) and has a number of challenges.
First, pity the internal compliance administrator urged on by a boss to certify the product so it can get to market quickly. Certify now and risk some vague, potential issues years in the future to be handled by the people over at the security response team then? Or refuse to “be flexible with the rules,” delaying certification and risk getting fired? Are most companies even staffed properly to handle what could be scores of required certifications depending on their product portfolio? Are they positioned to consider every potential breach, especially as the threat landscape evolves? Or will they introduce a serious technical depth of potential security issues in the future, especially in the IoT domain with long operational deployment.
Second, self-certification failures have been prompting severely stricter regulatory requirements, especially where critical infrastructure and societal damage is at stake. And, while there are some logical reasons for a company to self-certify, it also means the company takes on liability for those claims. Lastly, self-certification isolates the interpretations of the requirements – highly relevant in the security domain – which can lead to a market of siloed developments, disparate, proprietary solutions, and an uneven playing field.
Enter third-party certification, which has historically had a strong basis in the governmental eID and payment industry. Device makers can ensure a consistent standard of security is designed-in to the hardware and firmware of all devices, and the ecosystem has a vital role to play in this.
We all need to work together to identify and share industry best practice, so we can overcome current and future security threats and make sure everything is built on a common foundation of security and trust. This works so well that vulnerabilities in the eID and payment card domains are rare nowadays. Surely this is desirable for our consumer IoT, critical infrastructure and personal privacy? And, it suggests that additional security goals can be achieved.
The second prong, attestation, comes as the products are delivered and function in the field. Attestation is a technical means to make sure a product is genuinely what it claims to be, and still operates in a secure manner. Attestation can be used to translate the human-readable certificate of trust into something that’s machine-readable. Previously, to attest to the trustworthiness of a device, you had to take the package off a silicon device and examine its markings to ensure it was what it said it was. This isn’t very practical even for the professional evaluation labs, let alone end-consumers, and also is vulnerable to forgers.
Today, to manage this better and ensure scalability, devices have a Root of Trust that can provide the attestation chain from chip to full system. A product with this functionality can prove to its owner and the other devices and services it’s talking to that it is genuine and trusted, and those other devices in turn can trust it. It’s a key element of securing a device throughout the lifecycle, and showing the value of secured devices to the network it is in.
PSA Certified, founded by Arm in 2017 to provide a security framework for the IoT sector, has developed so that today it has more than 70 products PSA Certified across the world,
Ecosystem of trust
Technology alone isn’t enough to make an ecosystem. We at TrustCB9 are just one aspect of a rapidly expanding certification and attestation ecosystem that aims to ensure trusted, validated security from IP to system.
These include partnerships such as PSA Certified (founded by Arm, Brightsight, CAICT, Prove & Run, Riscure and UL) which is an open, industry-standard threat-modeling framework to ensure secure-by-design up through and including security consultation, evaluation and finally certification. PSA Certified is also concentrating on aligning with other schemes (such as GlobalPlatform SESIP, UL IoT Security Rating and ioXt Alliance) to further reduce fragmentation and improve the composite certifications reuse in other schemes.
In the end, third-party certification sets a common bar for everyone to protect the connected world. This enables companies to use certification to build or expand a trusted brand and position against competitors that have avoided certification or employed self-certification. And because it’s an ecosystem of companies dedicated to making the digital world more secure, it’s trusted: These companies put their reputations and business models on the line in the name of security certification.
The business value to the certification ecosystem is shorter time-to-market. Developers need to make a secure end product fast. One can risk time to market using a component of unknown security: Finding out that a core mechanism that’s depended on for the security, is in fact insecure causes a very expensive rush to fix late in the development cycle (even more so if that core mechanism is provided by another party).
Thus the evaluation and certification process needs to be predictably short. The time the product is in limbo for its security certification is very costly to developers and reduce security for all. After all, the attackers do not wait.
Some smaller companies worry that certification schemes could add costs to their product development that, because of their size, they can’t afford. It is quite the opposite: Certification and attestation help the ecosystem spread the cost with the reusable certifications of the platforms.
For example, a company taking a small control and communications module and layering software on top to make it a solution for farm irrigation now only has to worry about certification of its software running on the module. The security of the underlying hardware and OS has been validated and certified, and those costs are spread over the many users of that hardware and OS.
In short, through certification and attestation, companies now see a pathway to trust, just as much as they realize that the cost of inaction can be incalculable.
