In November 2024, the Information Technology Laboratory at the National Institute of Standards and Technology (NIST) released NIST Report 8517, which examines nearly 100 scenarios that highlight the extensive possibilities for hardware-related IT security failures.
Leveraging existing data on hardware weaknesses and design flaws documented in the Common Weakness Enumeration (CWE) and Common Vulnerabilities and Exposures (CVE) indexes, overlaid by the lab’s own research and evaluation, the report provides security failure scenarios that describe where each weakness typically occurs and its risk of exploitation.
NIST Report 8517 is useful for anyone desiring to understand the various ways computer hardware can experience security-related failures that can lead to malicious exploitation, data breaches, ransom demands, and their associated costs.
The 98 hardware security failure scenarios compiled by NIST are organized into seven categories, listed below in descending order based on the concentration of failure scenarios in each category.
Following are two of the more common failure points, specifically Improper Access Control and Improper Adherence to Coding Standards.
This most common weakness occurs when a “product does not restrict, or incorrectly restricts, access to a resource from an unauthorized actor.” Effective access control is universally considered a vital security function. In turn, it relies on the use of three primary protection mechanisms:
Improper access control may include improper physical access control, an insecure security identifier mechanism, or improper authorization.
Improper Physical Access Control. A security failure in this case allows a malicious human to obtain restricted information by exploiting physical access because the physical security features are insufficient. During debugging operations, an untrusted agent can read security-sensitive device information (such as encryption keys and manufacturing data) that is permanently stored in fuses but loaded into protected registers due to inadequate code that fails to take the debug mode into account.
Insecure Security Identifier Mechanism. In this case, there are several hardware security failure scenarios involving a malicious human initiating an unauthorized transaction. Examples include, but are not limited to:
Improper Authorization. This particular weakness can allow a variety of highly concerning security failure scenarios, including:
The NIST report describes 27 additional security failure scenarios stemming from Improper Access Control. As just one example, an attacker can gain full read-write access to a device by exploiting undocumented features—typically put there to allow for easier developer testing—that enable them to circumvent security controls. Any form of unauthorized access poses a threat to the security of information technology and sensitive data.
This common weakness occurs when a “product does not follow certain coding rules for development, which can lead to resultant weaknesses or increase the severity of the associated vulnerabilities.” This weakness can result from any of the following coding errors:
Failure to Properly Follow Specification by Caller. A security failure in this case allows an attacker to decipher cryptographic output because the cryptographic algorithm used by the IP block does not implement a requisite step.
Incorrect Provisioning of Specified Functionality. Two security failures can result from this weakness. In one, an attacker can compromise security due to an IP block that fails to perform according to its specification. In the other, an attacker can cause Denial of Service or possibly gain privileges by providing input to a finite state machine (FSM) that drives it into an undefined state, because the FSM code does not cover all possible state transitions.
Reliance on an Insufficiently Trustworthy Component. Security failures resulting from this error may allow attackers to compromise a system-on-a-chip because it relies on the composition of IP blocks, one of which is untrustworthy. Attackers can also compromise a system-on-a-chip because it contains a vulnerable component that cannot be updated, such as firmware or ROM used in secure booting.
Violation of Secure Design Principles. In this example, three security failure scenarios can result, including:
Weaknesses or faults in the design of hardware and software can result in vulnerabilities that are seen year after year because they have not been resolved. Too many developers and manufacturers build new devices on the foundations of established ones without giving serious thought to enhancing security features.
The U.S. Cybersecurity & Infrastructure Security Agency (CISA) is a vocal advocate for implementing Secure by Design principles in hardware and software design with the goal of significantly reducing the number of exploitable vulnerabilities before products are released for widespread use.
According to CISA, as we continue to introduce unsafe technology, including hardware and software, effective cybersecurity becomes increasingly difficult. “Out-of-the-box, products should be secured with additional features such as multifactor authentication, logging, and single sign-on available at no extra cost,” states the CISA website.
More than a few of the hardware security failures described in the previous section originate with hardware design weaknesses. The NIST report provides these 13 categories that describe where a security problem may exist in hardware design:
Two failure points that can lead to malicious exploits are highlighted below. They are related to General Circuit and Logic Design and the design of Power, Clock, Thermal, and Reset functionality.
Weaknesses in this category are related to hardware-circuit design and logic, such as CMOS transistors, finite state machines, and registers, as well as issues related to hardware description languages such as System Verilog and VHDL. A few examples in this category (CWE-1199) are weaknesses such as failure to disable reserved bits, incorrect register defaults or module parameters, incorrect selection of fuse values, and improper restriction of write-once bit fields.
Improper Restriction of Write-Once Bit Fields. In this example, a common security measure to protect register settings from potentially malicious modification by
Failure to implement write-once restrictions in hardware design can allow registers to be reprogrammed by software and written multiple times, thereby allowing exploitation by hackers. As we know, hackers don’t casually exploit vulnerabilities—their goal is to steal data for profit, which may involve sale on the dark web or a ransom demand to return the data back to the breached organization.
In this category, design weaknesses may occur at the platform level or at the system-on-a-chip level in system power, voltage, current, temperature, clocks, system state saving/restoring, and reset functionality. A few examples in this category (CWE-1206) are weaknesses such as improper lock behavior after power state transition, improper protection against voltage and clock glitches, comparison logic being vulnerable to power side-channel attacks, uninitialized value on reset for registers that contain security settings, and improperly preserved integrity of the hardware configuration state during a power save or restore operation.
Improper Lock Behavior After Power State Transition. In this example, the design error can lead to a hardware security failure that allows the lock to be set to “unlocked” after a change in power (to On, Off, or Sleep state, for example). Some common scenarios are that (1) the lock gets inadvertently cleared, (2) the values of the protected registers get inadvertently reset, or (3) the lock becomes programmable. Any of these scenarios could be exploitable.
The NIST Information Technology Laboratory recently released NIST Report 8517 “Hardware Security Failure Scenarios,” which outlines seven categories of hardware security failures ranging from access control issues to improper adherence to coding standards, totaling nearly 100 scenarios in all. The report also categorizes 13 types of hardware design weaknesses. All of these can lead to security failures that allow malicious exploitation and put sensitive data at risk.
Unfortunately, too many hardware (and software) design flaws result in vulnerabilities that recur year after year because they have not been resolved. This explains in part why the number of CVE records now exceeds 31,700. CISA continues to urge hardware manufacturers and software developers to implement Secure by Design principles to reduce the number of exploitable vulnerabilities in their products before taking them to market. Until this happens across the board, organizations can strengthen their security safeguards by conducting regular vulnerability testing and security risk assessments to discover many of these vulnerabilities before they can be exploited.