CAPEC-516: Hardware Component Substitution During Baselining
Attack Pattern ID: 516
Abstraction: Detailed
View customized information:
Description
An adversary with access to system components during allocated baseline development can substitute a maliciously altered hardware component for a baseline component during the product development and research phases. This can lead to adjustments and calibrations being made in the product so that when the final product, now containing the modified component, is deployed it will not perform as designed and be advantageous to the adversary.
Likelihood Of Attack
Low
Typical Severity
High
Relationships
This table shows the other attack patterns and high level categories that are related to this attack pattern. These relationships are defined as ChildOf and ParentOf, and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as CanFollow, PeerOf, and CanAlsoBe are defined to show similar attack patterns that the user may want to explore.
Nature
Type
ID
Name
ChildOf
Standard Attack Pattern - A standard level attack pattern in CAPEC is focused on a specific methodology or technique used in an attack. It is often seen as a singular piece of a fully executed attack. A standard attack pattern is meant to provide sufficient details to understand the specific technique and how it attempts to accomplish a desired goal. A standard level attack pattern is a specific type of a more abstract meta level attack pattern.
The adversary will need either physical access or be able to supply malicious hardware components to the product development facility.
Skills Required
[Level: Medium]
Intelligence data on victim's purchasing habits.
[Level: High]
Resources to maliciously construct/alter hardware components used for testing by the supplier.
[Level: High]
Resources to physically infiltrate supplier.
Mitigations
Hardware attacks are often difficult to detect, as inserted components can be difficult to identify or remain dormant for an extended period of time.
Acquire hardware and hardware components from trusted vendors. Additionally, determine where vendors purchase components or if any components are created/acquired via subcontractors to determine where supply chain risks may exist.
Example Instances
An adversary supplies the product development facility of a network security device with a hardware component that is used to simulate large volumes of network traffic. The device claims in logs, stats, and via the display panel to be pumping out very large quantities of network traffic, when it is in fact putting out very low volumes. The developed product is adjusted and configured to handle what it believes to be a heavy network load, but when deployed at the victim site the large volumes of network traffic are dropped instead of being processed by the network security device. This allows the adversary an advantage when attacking the victim in that the adversary's presence may not be detected by the device.
Related Weaknesses
A Related Weakness relationship associates a weakness with this attack pattern. Each association implies a weakness that must exist for a given attack to be successful. If multiple weaknesses are associated with the attack pattern, then any of the weaknesses (but not necessarily all) may be present for the attack to be successful. Each related weakness is identified by a CWE identifier.
Supply Chain: CWE does not currently cover Supply Chain in the way it is presented by CAPEC. Therefore, no mapping between the two corpuses can be made at this time.
Taxonomy Mappings
CAPEC mappings to ATT&CK techniques leverage an inheritance model to streamline and minimize direct CAPEC/ATT&CK mappings. Inheritance of a mapping is indicated by text stating that the parent CAPEC has relevant ATT&CK mappings. Note that the ATT&CK Enterprise Framework does not use an inheritance model as part of the mapping to CAPEC.
Description
This table shows the other attack patterns and high level categories that are related to this attack pattern. These relationships are defined as ChildOf and ParentOf, and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as CanFollow, PeerOf, and CanAlsoBe are defined to show similar attack patterns that the user may want to explore.
Content History
