In order to understand the many potential cyberattacks that threaten you and your organization, we turn to MITRE’s Common Weakness Enumeration (CWE) database as a key first step.

The CWE database is a community-developed list of software and hardware weakness types. These weakness types help categorize individual vulnerabilities, known as Common Vulnerabilities and Exposures (CVEs). By categorizing each CVE into its own CWE, we are able to approach software and hardware vulnerabilities with a common definition, and provide a baseline for weakness identification, mitigation, and prevention efforts. 

MITRE began tracking and analyzing CVEs in 1999, but quickly realized they needed a better way to organize the individual vulnerabilities, thus leading to the development of the CWE database in 2006. Since its inception fifteen years ago, the CWE database has grown from a handful of classes categorizing 1,500 vulnerabilities to over 200 classes of vulnerabilities categorizing over 100,000 CVEs. 

The ultimate purpose of CWEs is to help design more secure systems

The goal of both the CVE and CWE databases is to provide developers with the means to learn about, identify, and analyze the ever-growing list of vulnerabilities—ultimately, so future systems can be designed to avoid these pitfalls. Of course, we don’t live in a perfect world and perfect software does not exist. The often-cited statistic from Steve McConnell, author of Code Complete, estimates that there are anywhere between 15 and 50 vulnerabilities for every thousand lines of code. 

As systems become more complex, so too does the software that runs on them. Google estimates to run all of their programs—which include things like Gmail and Google Maps—takes 2 billion lines of code. And that’s just Google. When you consider the billions of IoT-connected devices, the world’s supercomputers, and the ever-growing number of smart cars on the roads today, there are trillions of lines of code containing millions (or even billions) of vulnerabilities.  Taking all of this into account, we can fully expect the CWE database to continue to grow at an exponential rate in the coming years. In fact, more than 24,000 CVEs were added from 2019 to 2020.

Increasingly complex systems mean more vulnerabilities

MITRE made the decision to include hardware weaknesses in the CWE database because, while cybersecurity is almost always addressed in software, infamous cyberattacks like Meltdown/Spectre were the result of hardware security flaws. These hardware flaws allowed for arbitrary locations in the memory of a program to be read, ultimately impacting any of the millions of devices using chips from Intel, ARM, or AMD. 

While Meltdown and Spectre were first discovered in 2017, the issue of hardware security isn’t going away anytime soon, and addressing it will be an increasingly important area of cybersecurity going forward. 

We’ve previously written about the major security concerns that increasingly complex software running on embedded systems causes. This is also true for increasingly complex hardware. Everything from “smart” cars to industrial controllers require sophisticated software and hardware to function, bringing with it hardware design weaknesses and software bugs that would-be bad actors could exploit in a cyberattack.

For this reason,  MITRE included hardware vulnerabilities in the CWE database for the first time in February of 2020. With this release, 32 different hardware CWEs were identified. By June of that same year, the number of identified hardware weakness types practically doubled to 59. At the time of this writing, a total of over 100 hardware design weaknesses have been identified and categorized by MITRE.

A closer look at the biggest threats of software weaknesses

Each year, MITRE compiles a list of the top 25 software CWEs that impacted systems. Rankings are based on the prevalence and severity of the CVEs within each CWE. The chart below depicts the top 25 CWEs from 2020. Topping the list is CWE-79, or cross-site scripting. 

Cross-site scripting occurs when untrusted data enters a web application and generates a web page with an embedded script. During page generation, the application does not prevent data from containing content that is executable by a web browser. A victim would then visit the web page via a web browser, and because the script comes from a web page, the victim’s web browser would execute the malicious code. This effectively violates the intention of the web browser’s same-origin policy, which states that scripts in one domain should not be able to access resources or run code in a different domain. Something important to note here is that, while this is the most prevalent CWE, the prevalence of severe CVEs within this class of weaknesses is quite low.  A severe CVE is a vulnerability in which an attack exploiting this vulnerability would be over the network and of low complexity, no special privilege would be needed for the attack to succeed, and no current work-around for the vulnerability currently exists. 

Out-of-bounds write vulnerabilities happen when software writes data past the bounds of its intended buffer. This vulnerability, if exploited, could result in anything from data corruption to code execution. As we can see in the graph, over half of all vulnerabilities in CWE-787 are severe. This is a sharp contrast to cross-site scripting, which only had 19 severe CVEs recorded in 2020.

Rounding out the top 3 is CWE-20, Improper Input Validation. This happens when software receives data, but does not properly validate that data, or does not attempt to validate it at all. Input validation is the practice of testing any data that is received by an application to ensure that it complies to a set of standards designed for that application. 

A closer look at the CWEs with the greatest impact on embedded systems

The CWE database is just the first step to addressing both hardware and software weaknesses found in embedded systems.

Once a software weakness is identified, a security patch is typically developed and pushed out to impacted systems—albeit with varying degrees of  speed and success. Meanwhile, hardware CWEs can be much more difficult to patch. This is because patches to the firmware are difficult to deploy, and can impact the processing performance of  a system. This is assuming that the vulnerability is able to be patched in the firmware in the first place. It is very likely that a vulnerability in the hardware would require a total replacement of that hardware, which is next to impossible in the field.

If we know that patches aren’t enough, we need a proactive way to address these weaknesses in hardware and software before attackers turn them into exploits. 

Addressing the most common and dangerous CWEs requires hardware-based security

Software vulnerabilities might be ubiquitous, but there are no shortage of cybersecurity options to address these issues. We mentioned security patches earlier as a common way of addressing known vulnerabilities in software, but security patches alone cannot solve the issue entirely. This is a reactive approach that can only fix the bug after it's been identified, and will do nothing to prevent the exploitation of the vulnerability before the patch can be issued. 

Rather than relying on software patches, a true defense-in-depth cybersecurity strategy that prevents the exploitation of the CWE is achievable by implementing a hardware-based defense mechanism, like Dover’s CoreGuard® oversight system.

The CoreGuard oversight system is a novel combination of hardware and software that prevents the exploitation of software vulnerabilities and immunizes processors against entire classes of network-based attacks. In fact, 100% of the CWEs in MITRE’s Top 25 are entirely protected against with the CoreGuard technology through our base set of micropolicies as well as a combination of web protection, sanitization, confidentiality, and access control micropolicies.

Preventing the exploitation of CWEs with CoreGuard

CoreGuard is able to provide this protection at the lowest possible level by integrating directly into the silicon, next to the host processor. The software components of CoreGuard are a set of rules, called micropolicies, that define what instructions are allowed or not allowed to be executed. These micropolicies are informed by metadata, which provides CoreGuard with the information and context it needs to make decisions about which instructions violate micropolicies. 

CoreGuard’s base set of micropolices include stack and heap protection, as well as our read, write, execute (RWX) micropolicy.  In addition to our base set of micropolicies, our confidentiality, sanitization, web protection, and access control micropolicies prevent the exploitation of all of the top 25 CWEs that made MITRE’s 2020 list. 

To learn more about how CoreGuard protects against the most dangerous CWEs impacting embedded systems, watch Dover’s webinar Securing Embedded Systems: Analyzing CWE Threats and Delivering Hardware-Based Defense-in Depth.