An organization’s ability to protect its most sensitive data boils down to ensuring that it has all its bases covered. That’s hard to do when there could be cracks in the foundation.Â
The cybersecurity industry has traditionally focused on identifying and patching software vulnerabilities, but it is easy to forget that software runs on semiconductor chips – and if this “hardware” in a product or system is compromised, the consequences could be equally bad or worse.Â
Hardware vulnerabilities are almost always serious in nature, and you cannot simply patch hardware. The further into product development you get, the costlier – and riskier – security issues become.Â
So, why is hardware security often overlooked, and what makes this a recipe for disaster? Why is transparency during the entire chip development cycle more vital than ever, and how will the implementation of a hardware bill of materials (HBOM) not only contribute to that peace of mind but enable you to better secure and maintain electronic products? Let’s discuss.Â
A deeper understanding of how vulnerable chips areÂ
For years, it was commonly assumed that semiconductor chips could only be compromised through physical manipulation, but that belief has been debunked.Â
In 2017, security researchers discovered the Spectre and Meltdown vulnerabilities – fundamental security flaws that existed in almost every computer chip manufactured in the past two decades. If exploited, hackers could gain access to data on microprocessors that were considered fully secure. Â
Spectre and Meltdown brought greater attention to security weaknesses at the hardware level, but they also revealed that hardware design flaws can, in fact, be taken advantage of remotely. Â
At the Graz University of Technology in Austria, a team of researchers developed a Spectre-based attack called NetSpectre. Unlike Spectre, which needs attacker-controlled code to run on the targeted device, NetSpectre can be performed remotely. The research suggests this vulnerability “marks a paradigm shift from local attacks, to remote attacks, exposing a much wider range and a larger number of devices to Spectre attacks.” Â
This revelation, along with the fact that hardware complexity is progressing at a rate akin to software code size and that there’s been a rapid growth of discovered hardware vulnerabilities (CVEs) over the past few years, should make organizations more concerned about the makeup and potential risks in hardware. But this level of transparency isn’t mandatory – not like it’s starting to be with software.   Â
The growing push for a software bill of materialsÂ
In the manufacturing world, a bill of materials (BOMs) is a relatively common term. It is a complete inventory of all the raw materials, parts, and components – and their quantities – needed to create a product. Recently, the desire to complement this information with software security details has picked up steam in the form of a software bill of materials (SBOM) – and for good reason. Â
According to Synopsys’ 2022 Open Source Security and Risk Analysis (OSSRA) report, the average software application relies on 500 open-source libraries and components. The report found that 98% of applications use open source, while over 75% of the code in the average software application consists of open-source components. Oftentimes, users are completely unaware of this. That is where SBOMs factor in. Â
An SBOM lists all the components in a software application, identifies what version they are, and points out if any parts contain security weaknesses that could expose the entire application to attacks from bad actors. Â
To create more transparency in the software supply chain, President Biden issued an executive order in 2021 making SBOMs mandatory for software vendors contracting with the federal government. That way, government agencies will not only know the “ingredients” in the software they utilize, but they can quickly respond to new security weaknesses as they arise. Â
The recently introduced bipartisan bill to strengthen cybersecurity for medical devices also explicitly lists the SBOM as a key requirement for providing transparency into the security posture of all software components of a medical device. Unfortunately, the same “rules” don’t apply to hardware. This is unsettling, as hardware security should be subjected to the same level of scrutiny as software, if not more. Â
What a hardware bill of materials should featureÂ
These days, chips are everywhere. They’re in the IoT devices littered throughout your house. They’re in phones, computers, cars, medical devices, and more. The U.S. is also becoming more invested in chip manufacturing – as evidenced by the recently passed CHIPS act that includes $52 billion for strengthening the nation’s computer chip industry.Â
Unlike software, however, hardware can’t be patched and the further you get into chip development, the harder it is to shore up any issues. Once a vulnerability is discovered, it’s oftentimes too late, and organizations are left scrambling to determine the root cause of the problem.Â
​​​​​The “Augury” flaw that affects Apple’s M1 chips and the “unpatchable” hardware vulnerability discovered last summer are further proof that taking a reactive approach to hardware security opens you up to significant exposure. While we haven’t seen an Experian-level personally identifiable information (PII) security breach at the hardware level (yet), is that really a risk worth taking? Â
It’s time to get proactive using HBOMs – a detailed list of the hardware components’ security, including security validation – to track and document hardware security vulnerabilities. HBOMs should include:Â
- Documentation of the security intention at the product planning stage based on security features and verification requirementsÂ
- The threat model that was considered during the design, as well as possible attack vectors and abilities of would-be attackersÂ
- Embedded security design components and protection systems to neutralize attacksÂ
- IP blocks developed in-house and by third parties, including their security postureÂ
- The security verification methods that were employed and complete documentation of the outcomesÂ
- Standards applied and their documentation, including Common Weakness Enumerations (CWEs) or ISO standards like ISO/SAE 21434 (Road Vehicle Cybersecurity engineering), ISO/IEC 19790 (Security for cryptographic modules), or ISO/IEC 15408 (Common Criteria)Â
- Security certifications that were used, including their documentationÂ
If you don’t understand the security posture of semiconductor chips and what products currently use them, you’re operating without all the information and potentially opening your organization up to security concerns. Â
HBOMs are crucial for ensuring the security of all electronic devices. They create transparency, from the chip development lifecycle through the circulation of the electronic device itself. HBOMs tell you what’s in the product – and how secure it is – so you can make an informed decision before purchasing it.Â
Real product security requires a holistic approach  Â
​​​​​The only way to sufficiently secure an electronic product is to make sure all components within it are accounted for. Over the past few years, we’ve made significant strides to be transparent about software. The same can’t be said about hardware.    Â
As hackers continue to explore new hardware vulnerabilities and ways to exploit them, we must require the same standards of hardware as we do of software. That starts with enforcing the use of the HBOMs alongside SBOMs to create a holistic view of cybersecurity.Â
In doing so, you can ensure you have complete transparency during the development and lifecycle of electronic products, giving you the insight to respond quickly and effectively to any incident. Â
By standardizing HBOMs and using them in conjunction with SBOMs, we can fuel a holistic approach that ensures more products are secure and we can react swiftly to cyber incidents as they arise.Â
Andreas Kuehlmann BioÂ
Dr. Andreas Kuehlmann is the Executive Chairman and CEO at Cycuity (formerly Tortuga Logic). Kuehlmann has spent his career in semiconductor design, software development, and cybersecurity, and served as an adjunct professor at UC Berkeley’s Department of Engineering and Computer Science for 14 years. Kuehlmann was previously general manager of the Software Integrity Group at Synopsys and has held top positions at Coverity and Cadence. He holds a Ph.D. in Electrical Engineering from the Technical University Ilmenau, Germany.Â
Â