As modern computer systems become more complex and interconnected, we are seeing more vulnerabilities than ever before. As attacks become more pervasive and sophisticated, they are often progressing past the software layer and compromising hardware. As a response, the industry has been working to deliver microarchitectural improvements and today, implementing hardware-based security is widely recognized as a best practice.
However, hardware-based security has its own set of challenges when not designed, implemented or verified properly. Combined with the fact that we are seeing increasingly sophisticated methods to exploit hardware by chaining them together with software vulnerabilities, it’s evident that the industry needs a better and more in-depth understanding of the common hardware security vulnerabilities taxonomy, including information on how these vulnerabilities get introduced into products, how they can be exploited, their associated risks, as well as best practices to prevent and identify them early on in the product development lifecycle.
Today, a key resource for tracking software vulnerabilities exists in MITRE’s Common Weakness Enumeration (CWE) system, which is also complemented by the Common Vulnerability and Exposures (CVE) system.
A simple way to differentiate the two is that CWE includes a taxonomy of common security vulnerability types and provides different views for a user to traverse different categorical buckets, whereas the CVE maintains the list of specific vulnerability instances that have already been found and reported publicly. Multiple CVEs are usually mapped to specific CWEs.
Essentially, the two systems work hand-in-hand to provide the ultimate vulnerability reference guide. These resources aim to educate architects and developers to identify potential mistakes when designing and developing software products. At the same time, they enable security researchers and tool vendors to pinpoint current gaps, so they can offer better tools and methodologies to automate the detection of common software security issues.
With the growing awareness of hardware vulnerabilities, the CWE could be enhanced to include relevant entry points, common consequences, examples, countermeasures and detection methods from the specific hardware perspective. Furthermore, there are hardware-centric weaknesses that are related to the physical properties of hardware devices (e.g., temperature, voltage glitches, current, wear out, interference, and more) which the CWE does not yet categorize.
Due to these missing reference materials for hardware vulnerabilities in the CWE, researchers do not have the same standard taxonomy that would enable them to share information and techniques with one another. If we expect hardware vendors and their partners to collectively deliver more secure solutions, we must have a common language for discussing hardware security vulnerabilities.
Over the past few years, Intel researchers have been active in raising public awareness on common hardware security vulnerabilities (through academia, at conferences, and even with the industry’s first hardware capture-the-flag competition). But more can always be done. Here are six ways the industry would benefit from a standardized Hardware CWE:
1. Product architects and designers could gain a deeper understanding of the common hardware security pitfalls, allowing them to potentially avoid repeat mistakes when creating solutions.
2. Verification engineers could be more fluent in the commonly made security mistakes and how they can be effectively detected at various stages of the product development lifecycle. This would enable them to devise proper verification plan and test strategies for improving the security robustness of products.
3. Security architects and researchers could better focus their energy on systemic issues and work to identify effective mitigations that help eliminate risks and/or make exploitation much more difficult for attackers.
4. Electronic Design Automation (EDA) vendors could prioritize and expand their verification tool features and offerings. This could improve the effectiveness of their tools in guiding users to avoid the introduction of common vulnerabilities. It could also provide a common platform for EDA tool users to compare and benchmark the capabilities of different tool options, enabling them to identify the right ones that meet their specific needs.
5. Educators could develop training materials and best practices that focus on the most relevant areas of concern, so university curriculum and corporate trainings could help audiences gain the necessary skills they need.
6. Security researchers could leverage a common taxonomy to communicate without ambiguities, facilitating learning exchange, systematic study and collaboration. And a public database would also make the research field more accessible for aspiring researchers.
As our industry moves forward to combat the latest threats, it is vital that we invest in research, tooling and the proper resources to catalog and evaluate both software and hardware vulnerabilities.
Today, categorizing hardware vulnerabilities, root causes, and mitigation strategies often feels like an uphill battle. As hardware vulnerabilities continue to get more complex and challenging for the industry, creating a common taxonomy for discussing, documenting and sharing hardware-based threats becomes paramount.
Let’s work together as an industry to ensure that we are speaking the same language when it comes to researching and mitigating the hardware vulnerabilities of the future.
- Arun Kanuparthi, Offensive Security Researcher, Intel
- Hareesh Khattri, Offensive Security Researcher, Intel