An adversary alters the functionality of a field-programmable gate array (FPGA) by causing an FPGA configuration memory chip reload in order to introduce a malicious function that could result in the FPGA performing or enabling malicious functions on a host system. Prior to the memory chip reload, the adversary alters the program for the FPGA by adding a function to impact system operation.
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 FPGA programming/configuration-related systems in a chip maker’s development environment where FPGAs can be initially configured prior to delivery to a customer or have access to such systems in a customer facility where end-user FPGA configuration/reconfiguration can be performed.
Skills Required
[Level: High]
An adversary would need to be skilled in FPGA programming in order to create/manipulate configurations in such a way that when loaded into an FPGA, the end user would be able to observe through testing all user-defined required functions but would be unaware of any additional functions the adversary may have introduced.
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 FPGA programming and program uploads to FPGA chips.
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 and the ability to alter the configuration/programming of FPGAs in organizational systems, introduces a trojan backdoor that can be used to alter the behavior of the original system resulting in, for example, compromise of confidentiality of data being processed.
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.
[REF-662] Jeremy Muldavin. "Assuring Microelectronics Innovation for National Security & Economic Competitiveness (MINSEC)". Office of the Deputy Assistant Secretary of Defense for Systems Engineering. 2017-11.
Content History
Submissions
Submission Date
Submitter
Organization
2021-06-24
(Version 3.5)
CAPEC Content Team
The MITRE Corporation
Modifications
Modification Date
Modifier
Organization
2022-02-22
(Version 3.7)
CAPEC Content Team
The MITRE Corporation
Updated References
2022-09-29
(Version 3.8)
CAPEC Content Team
The MITRE Corporation
Updated Taxonomy_Mappings
More information is available — Please select a different filter.
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
