CAPEC-671: Requirements for ASIC Functionality Maliciously Altered
Attack Pattern ID: 671
Abstraction: Detailed
View customized information:
Description
An adversary with access to functional requirements for an application specific integrated circuit (ASIC), a chip designed/customized for a singular particular use, maliciously alters requirements derived from originating capability needs. In the chip manufacturing process, requirements drive the chip design which, when the chip is fully manufactured, could result in an ASIC which may not meet the user’s needs, contain malicious functionality, or exhibit other anomalous behaviors thereby affecting the intended use of the ASIC.
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.
An adversary would need to have access to a foundry’s or chip maker’s requirements management system that stores customer requirements for ASICs, requirements upon which the design of the ASIC is based.
Skills Required
[Level: High]
An adversary would need experience in designing chips based on functional requirements in order to manipulate requirements in such a way that deviations would not be detected in subsequent stages of ASIC manufacture and where intended malicious functionality would be available to the adversary once integrated into a system and fielded.
Consequences
This table specifies different individual consequences associated with the attack pattern. The Scope identifies the security property that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in their attack. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a pattern will be used to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Scope
Impact
Likelihood
Integrity
Alter Execution Logic
Mitigations
Utilize DMEA’s (Defense Microelectronics Activity) Trusted Foundry Program members for acquisition of microelectronic components.
Ensure that each supplier performing hardware development implements comprehensive, security-focused configuration management including for hardware requirements and design.
Require that provenance of COTS microelectronic components be known whenever procured.
Conduct detailed vendor assessment before acquiring COTS hardware.
Example Instances
An adversary with access to ASIC functionality requirements for various customers, targets a particular customer’s ordered lot of ASICs by altering its functional requirements such that the ASIC design will result in a manufactured chip that does not meet the customer’s capability needs.
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.
CWE leads to CAPEC: This entry highlights the rare case where a CAPEC creates an instance of a CWE, as opposed to the usual other way around. At this time, this field only includes mappings to weaknesses that cause the CAPEC, instead of CWEs that could arise due to the CAPEC.
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.