Hardware Security: A Critical Piece Of The Cybersecurity Puzzle

Cybersecurity is a critical foundation of our rapidly expanding digital world spanning hardware and software that powers everything from our personal devices to the global infrastructure. Over the past decade, significant progress has been made in many security domains, especially in maturing secure software development processes. So far, hardware security has received limited attention, however recently uncovered chip vulnerabilities, such as Spectre and Meltdown, serve as a harsh reminder that our systems can only be as secure as its weakest link.

According to NIST (National Institute of Standards and Technology) there has been an exponential growth in hardware vulnerabilities in the last few years, rapidly catching up with the growth seen in software over the last decades. While software can be patched, hardware cannot be updated easily, thus dramatically increasing the potential negative business impact of security flaws.

Building secure products, whether software or hardware, is a journey that not only involves technical solutions but requires adjusting business priorities, maturing product organizations and processes, as well as establishing clear metrics to assess business risks and progress towards their mitigation. In this blog, I will draw on my recent experience in building a software application security business to discuss three aspects that are vital for addressing security holistically.

Security is a journey

There is no simple cookbook for cybersecurity such as “Do X and you are secure.” It is rather a constant process of learning and maturing, adjusting organizations and processes, and shifting trade-offs of business risks and objectives. Cybersecurity requirements are relatively new to many organizations and necessitate resources and focus to tackle them.

Some of the questions that need to be sorted out are:

• What is our security risk and what investments do we need to make to best mitigate it?
• Who owns security and is accountable? Is it the (often newly created) dedicated security team or the product development organization?
• Who calls the shots to declare a product secure enough for shipment and who has the authority to hold it back if needed?
• Where do we start and what metrics should we use to measure progress and declare success?

The software CWE (Common Weakness Enumeration) list established by MITRE in 2006 played a critical role in maturing software application security over the past decade. It provides valuable guidance for understanding cyber risks, where and what to invest for mitigation and offers a means to report product security metrics to customers. I expect that the very recent expansion to hardware CWEs will drive a similar maturing process of hardware security.

Security must not get in the way

As security becomes another product requirement, there is a natural concern whether it slows down the development process, delays the time to market and therefore impacts the business. For security programs to be successful, it is imperative that it minimally weighs on development velocity, to avoid creating conflicting choices between product security and timely product delivery.

Key elements of a successful security program include:

• Business objectives and priorities need to be clearly defined upfront and be aligned among all stakeholders.
• The development and security teams need to closely collaborate throughout the product life cycle from requirement collection to product shipment and support.
• Product development, functional testing and security testing must be tightly integrated and operate in lock-step to ensure issues are found and addressed as early as possible.
• Security testing tools must support the daily development process rather than getting in its way. Among others, this means automated applications of tests in an ongoing manner, low false positive rate and clear remediation advice supporting quick understanding and fixing issues.
• Security oversight and governance needs to be done in real time through meaningful metrics that allow quick intervention and avoids late surprises, which I sometime call the “green/green/green/dark-red” syndrome.

Over the past decade, we have learned many lessons while establishing comprehensive software security programs. I expect that this experience can provide valuable guidance to further mature our approach to hardware security.

Security cannot be solved in silos

Today cybersecurity is addressed in mostly disconnected silos. Yet, security is a system property that, in order to be comprehensive and responsive, must be considered across domains (hardware, software, firmware, OS, application, network, cloud, etc.) and across the system lifecycle (design, development, manufacturing, supply chain, support and maintenance, etc.). For example, when the Spectre hardware vulnerability was discovered, it was clear that impacted microprocessors are everywhere and cannot be replaced quickly (not to mention the time it takes to redesign and manufacture new parts.) As a result, the attention quickly shifted to software and how the operating system layer and software applications running on it could be hardened to prevent possible hardware attacks.

There is an opportunity to improve overall system security protection within domains “by breadth” and across the lifecycle “in depth,” raising two important questions:

• How can we integrate security solutions within a domain to strengthen their coverage by applying complementary techniques and sharing system insight between them?
• How can we integrate security solutions “downstream” across the lifecycle to implement a more adaptive defense in depth and “upstream” to enable faster remediation to security incidences?

Hardware security is a critical foundation of overall system security. I expect that its integration with “downstream” solutions will enable a more impermeable and higher-responsive approach to cybersecurity.

Tackling hardware security

Tortuga Logic has developed powerful technologies to uncover security vulnerabilities early in the design process of semiconductor devices in support of the above-mentioned paradigm to “shift security left.” Tortuga’s Radix line of products augments existing chip verification methodologies and flows and provides broad coverage of the hardware CWEs. It is architected and integrated in support of key elements of a robust security program outlined above:

• Security requirements are specified upfront, encoded as compact rules, and mapped to corresponding CWE categories. They are easy to comprehend and provide an effective collaboration tool between the security team – which may not be familiar with all design details – and the design & verification teams – which often lacks security expertise.
• Testing is run continuously throughout the design and verification process. Flagged security issues are processed and remediated in the same workflow as functional bugs. Moreover, when applied during hardware acceleration/emulation, it can check for system-level security issues triggered by software that runs on the hardware.
• The analysis is sound, i.e., it does not produce false negatives – every discovered issue is either a valid security issue or a weakness that is out of the scope of the security teams’ threat models.
• Comprehensive reporting provides ongoing insight into the design’s security status and allows quick course correction if needed. Moreover, it offers a means for product security sign-off and documentation for customers.
• In case of security vulnerabilities found in the field, it can postmortem simulate discovered exploit scenarios and validate any remediation in either hardware or software.

Tortuga Logic is well positioned to help chip design organizations to address hardware security in an efficient manner. It provides a critical building block for a comprehensive solution for system cybersecurity.