Difference between pages "Diversity, Equity, and Inclusion" and "System Hardware Assurance"

From SEBoK
(Difference between pages)
Jump to navigation Jump to search
 
 
Line 1: Line 1:
 
----
 
----
'''''Lead Authors:''''' ''Alan Harding'', ''Alice Squires''
+
 
 +
'''''Authors: ''' Michael Bear, Donald Davidson, Shawn Fetterolf, Darin Leonhardt, Daniel Radack, Karen Johnson, Elizabeth A. McDaniel    '''Contributors:''' Michael Berry, Brian Cohen, Diganta Das, Houman Homayoun, Thomas McDermott''
 +
 
 
----
 
----
 +
This article describes the discipline of hardware assurance, especially as it relates to systems engineering. It is part of the [[Systems Engineering and Quality Attributes | SE and Quality Attributes]] Knowledge Area.
 +
 +
==Overview==
 +
 +
{{Term|system hardware assurance (glossary)|System hardware assurance}} is a set of system security engineering activities (see [[System Security]] for more information) undertaken to quantify and increase the confidence that electronics function as intended and only as intended throughout their life cycle, and to manage identified risks. The term ''hardware'' refers to electronic components, sometimes called integrated circuits or chips. As products of multi-stage processes involving design, manufacturing and post-manufacturing, packaging, and test, they must function properly under a wide range of circumstances. Hardware components – alone and integrated into subcomponents, subsystems, and systems – have weaknesses and vulnerabilities enabling exploitation. Weaknesses are flaws, bugs, or errors in design, architecture, code, or implementation. Vulnerabilities are weaknesses that are exploitable in the context of use (Martin 2014). 
 +
 +
Hardware assurance is conducted to minimize risks related to hardware that can enable adversarial exploitation and subversion of functionality, counterfeit production, and loss of technological advantage.  Challenges include increasing levels of sophistication and complexity of hardware architectures, integrated circuits, operating systems, and application software, combined with supply chain risks, emergence of new attack surfaces, and reliance on global sources for some components and technologies.
 +
 +
After identifying concerns and applicable mitigations, hardware assurance offers a range of possible activities and processes. At the component level, hardware assurance focuses on the hardware itself and the supply chain used to design and manufacture it; at the subcomponent, subsystems, and system levels, hardware assurance incorporates the software and firmware integrated with the component.
 +
 +
Engineering efforts to enhance trust in hardware have increased in response to complex hardware architectures, the increasing sophistication of adversarial attacks on hardware, and globalization of supply chains. These factors raise serious concerns about the security, confidentiality, integrity, and availability as well as the provenance and authenticity of hardware. The “root of trust” (NIST 2020) of a system is typically contained in the processes, steps, and layers of hardware components and across the systems engineering development cycle. System hardware assurance focuses on hardware components and their interconnections with software and firmware to reduce risks to proper function or other compromises of the hardware throughout the complete life cycle of components and systems. Advances in hardware assurance tools and techniques will strengthen designs, and enhance assurance during manufacturing, packaging, test, and deployment and operational use.
 +
 +
==Life Cycle Concerns of Hardware Components==
 +
 +
Hardware assurance should be applied at various stages of a component’s life cycle from hardware architecture and design, through manufacturing and testing, and finally throughout its inclusion in a larger system. The need for hardware assurance then continues throughout its operational life including sustainment and disposal.
  
Diversity, Equity, and Inclusion (DEI) foster increased engagement, productivity, and innovation in an organization.
+
As semiconductor technology advances the complexity of electronic components, it increases the need to “bake-in” assurance. Risks created during architecture, design, and manufacturing are challenging to address during the operational phase. Risks associated with interconnections between and among chips are also a concern. Therefore, improving a hardware assurance posture must occur as early as possible in the life cycle, thereby reducing the cost and schedule impacts associated with “fixing” components later in the life cycle of the system.
  
==Introduction==
+
A conceptual overview of the typical hardware life cycle (Figure 1) illustrates the phases of the life cycle of components, as well as the subsystems and systems in which they operate. In each phase multiple parties and processes contribute a large set of variables and corresponding attack surfaces. As a result, the potential exists for compromise of the hardware as well as the subcomponents and systems in which they operate; therefore, matching mitigations should be applied at the time the risks are identified.
Systems engineers play a pivotal role in integrating concepts of diversity, equity, and inclusion within both the team and in the system design and development:
 
#Ensuring that the systems engineering team and its leadership is inclusive and welcomes a diverse range of talent, and where necessary taking deliberate action to provide equity.
 
#Ensuring that the systems we realise are as accommodating as possible of the differences within the entire stakeholder community. This is known as “inclusive engineering”.
 
  
Failure to address either aspect results in sub-optimal outcomes whether in terms of missed solutions, lower productivity, or delivering a system that does not fully meet the needs of the whole stakeholder community, i.e. failing to meet the ultimate goal of delivering a total optimal system solution.
+
[[File:Component_Lifecycle_(rev_a)_-_MJB_ver2.jpg|thumb|center|800px|'''Figure 1. Component Life Cycle.''' (SEBoK Original)]]
Systems engineers are responsible for effectively communicating the importance and value of diversity, equity, and inclusion in enabling, promoting, and advancing systems engineering and systems approaches to address complex societal and technical global challenges. 
 
  
Figure 1 shows how an inclusive development approach contributes to realizing inclusive solutions, within the context of the human system (whether within an organisation, country, or the world), itself set within the context of the natural world. The natural world is shown because of the strong linkage between the full lifecycle of engineered products (from concept to disposal) and sustainable development. For instance:
+
Both the value of the hardware component and the associated cost of mitigating risks increase at each stage of the life cycle. Therefore, it is important to identify and mitigate vulnerabilities as early as possible. It takes longer to find and fix defects later, thereby increasing the complexity of replacing hardware with “corrected” designs that create system integration issues. In addition to cost savings, early correction and mitigation avoid delays in creating an operational system. It is essential to re-assess risks associated with hardware components throughout the life cycle periodically, especially as operational conditions change.
*Water pollution from industrial plants affecting those who live nearby
 
*Air pollution from cars affecting pedestrians and those who live near major roads
 
*Product end of life/disposal effects e.g. hazardous substances, contribution to land-fill
 
  
[[File:DEI_Figure1.png|thumb|450px|center|'''Figure 1. Relationship between Inclusive Approach and Inclusive Product.''' (SEBoK Original)]]
+
Hardware assurance during system sustainment is a novel challenge given legacy hardware and designs with their associated supply chains. In long-lived high-reliability systems, hardware assurance issues are compounded by obsolescence and diminished sourcing of components, thereby increasing concerns related to counterfeits and acquisitions from the gray market.  
  
==Definitions of Diversity, Equity, and Inclusion==
+
==Function as Intended and Only as Intended==
The following definitions are taken from the Accreditation Board for Engineering and Technology (ref. 1), where they provide a reference point for conversations and materials about diversity, equity and inclusion.
+
Exhaustive testing can check system functions against specifications and expectations; however, checking for unintended functions is problematic. Consumers have a reasonable expectation that a purchased product will perform as advertised and function properly (safely and securely, under specified conditions) – but consumers rarely consider if additional functions are built into the product. For example, a laptop with a web-conferencing capability comes with a webcam that will function properly when enabled, but what if the webcam also functions when turned off, thereby violating expectations of privacy? Given that a state-of-the-art semiconductor component might have billions of transistors, “hidden” functions might be exploitable by adversaries. The statement “function as intended and only intended” communicates the need to check for unintended functions.
*{{Term|Diversity (glossary)|Diversity}} is the range of human differences, encompassing the characteristics that make one individual or group different from another. Diversity includes, but is not limited to, the following characteristics: race, ethnicity, culture, gender identity and expression, age, national origin, religious beliefs, work sector, physical ability, sexual orientation, socioeconomic status, education, marital status, language, physical appearance, and cognitive differences.
 
*{{Term|Equity (glossary)|Equity}} is the fair treatment, access, opportunity and advancement for all people, achieved by intentional focus on their disparate needs, conditions and abilities. Achieving equity requires understanding of historical and systemic patterns of disparity to address and eliminate barriers, and remove participation gaps as part of a comprehensive strategy to achieve equitable outcomes and social justice.
 
*{{Term|Inclusion (glossary)|Inclusion}} is the intentional, proactive, and continuing efforts and practices in which all members respect, support, and value others. An inclusive environment provides equitable access to opportunities and resources, empowers everyone to participate equally, and offers respect in words and actions for all.
 
  
In its work, the International Council on Systems Engineering (INCOSE) uses the compound term Diversity, Equity and Inclusion (abbreviated to DEI) when referring to the broad subject matter. The definition of diversity given encompasses a wide range of characteristics. As an example, Figure 2 shows 28 of these characteristics recognised by INCOSE (ref. 2) grouped into five areas: intrinsic, employment, environment, interaction, and family. The figure shows the relevance of these characteristics to the INCOSE Systems Engineering Certification Program.
+
Hardware specifications and information in the design phase are needed to validate that components function properly to support systems or missions. If an engineer creates specifications that support assurance that flow down the system development process, the concept of “function as intended” can be validated for the system and mission through accepted verification and validation processes. “Function only as intended” is also a consequence of capturing the requirements and specifications to assure the product is designed and developed without extra functionality. For example, a Field Programmable Gate Array (FPGA) contains programmable logic that is highly configurable; however, the programmable circuitry might be susceptible to exploitation.  
  
[[File:DEI_Figure2.png|thumb|500px|center|'''Figure 2. Categorized Dimensions of Diversity.''' (SEBoK Original, adapted from (Harding and Pickard 2019))]]
+
Given the specifications of a hardware component, specialized tools and processes can be used to determine with a high degree of confidence whether the component’s performance meets specifications. Research efforts are underway to develop robust methods to validate that a component does not have capabilities that threaten assurance or that are not specified in the original design. Although tools and processes can test for known weaknesses, operational vulnerabilities, and deviations from expected performance, all states of possible anomalous behavior cannot currently be determined or predicted.  
  
==Relevance of Diversity, Equity, and Inclusion to Engineering==
+
Data and information can be used to validate the component’s function and should be collected from multiple sources including designers, developers, and members of the user community. Designers and developers can provide deep understanding of the component’s intended function and provide tests used to verify its functional performance before fielding. The merging of component design and development information with extensive field data, including third-party evaluation, contribute to assurance that the component is performing specified functions and that no unintended functionality is observed. 
Engineers apply ingenuity, innovation, and systematic approaches to solve challenging problems. Life experience and academic research shows us that bringing a wide range of skills, knowledge, and thinking styles to bear on a problem is the most effective way to accelerate and improve the intended outcomes. These outcomes include improved “…financial performance, greater innovation and creativity, increased employee productivity and retention, improved customer or client orientation, and increased customer or client satisfaction.(ref. 3).  Hunt et al. (ref. 4) have found that companies at the forefront of gender and ethnic/cultural diversity in their leadership perform better financially.  
+
==Risks to Hardware==
By contrast, a team of people with the same cultural background, life experiences, education, and thinking style could be expected to be relatively less effective and more prone to identifying predictable solutions. The US National Academy of Engineering (ref. 5) note the opportunity cost of a lack of diversity in terms of “designs not thought of, in solutions not produced.
+
Modern systems depend on complex microelectronics, but advances in hardware without attention to associated risks can expose critical systems, their information, and the people who rely on them. “Hardware is evolving rapidly, thus creating fundamentally new attack surfaces, many of which will never be entirely secured”. (Oberg 2020)  Therefore, it is imperative that risk be modeled through a dynamic risk profile and be mitigated in depth across the entire profile. Hardware assurance requires extensible mitigations and strategies that can and do evolve as threats do. Hardware assurance methods seek to quantify and improve confidence that weaknesses that can become vulnerabilities that create risks are mitigated.
  
Inclusion, or ensuring a sense of inclusion in everyone, is necessary to ensure that all team members genuinely feel and believe that they belong and hence are able to use their talents and unique outlook to the maximum degree. By contrast, a lack of inclusion might make someone feel present but not involved or valued with the effect that the team as a whole does not deliver its best possible results.  
+
Most hardware components are commercially designed, manufactured, and inserted into larger assemblies by multi-national companies with global supply chains. Understanding the provenance and participants in complex global supply chains is fundamental to assessing risks associated with the components.  
  
Equity is not the same as equality, nor is it the same as inequality. It is simply giving more to those who need it, which is proportionate to their own circumstances, in order to ensure that everyone has the same opportunities. In an engineering context this might mean providing more support to a disadvantaged student so they can reach their full potential, or providing additional support or time to a team member with a condition such as dyslexia.  
+
Operational risks that derive from unintentional or intentional features are differentiated based on the source of the feature. Three basic operational risk areas related to goods, products, or items are: failure to meet quality standards, maliciously tainted goods, and counterfeit hardware. Counterfeits are usually offered as legitimate products, but they are not. They may be refurbished or mock items made to appear as originals, re-marked products, the result of overproduction, or substandard production parts rejected by the legitimate producer. Counterfeit risks and substandard quality offer avenues for malware insertion and potential impacts to overall system performance and availability.  
  
==Relevance of Diversity, Equity, and Inclusion to Systems Engineering==
+
Failure to follow quality standards including safety and security standards, especially in design, can result in unintentional features or flaws being inadvertently introduced. These can occur through mistakes, omissions, or lack of understanding how features might be manipulated by future users for nefarious purposes. Features introduced intentionally for specific purposes can also make the hardware susceptible to espionage or control of the hardware at some point in its life cycle.
DEI is vital to successful systems engineering because of the range of contexts in which it is applied and the consideration of multiple stakeholder viewpoints at the heart of the approach. Systems engineering is applied to a wide range of system types in a broad variety of contexts–engineered systems range from micro­electronics to aircraft, from abstract systems to smart cities. Systems engineers may be working with a customer, a prime contractor or integrator, a supplier or product manufacturer, a research/technology organisation, or a government body. And these activities take place all over the globe, often as part of consortiums or complex partnered programmes involving multiple organisations, countries, and cultures.
 
  
Applying systems engineering requires consideration of multiple viewpoints (such as the user, maintenance, safety, security) to achieve the proper holistic view of problem and solution. This means that the systems engineering team must be able to understand and work with a wide range of stakeholders. The transdisciplinary and integrative nature of systems engineering across other disciplines and activities, again, means that the systems engineering team needs to understand and work well with all the disciplines and specialities involved in realising a system (ref. 6).
+
== Quantify and Improve Confidence   ==
 +
The quantification of hardware assurance is a key technical challenge because of the complex interplay among designer, manufacturer and supply chains, and adversarial intent, as well as the challenge of defining “security” with respect to hardware function. Quantification is necessary to identify and manage hardware risks within program budgets and timeframes. It enables a determination of the required level of hardware assurance and whether quantification is achievable throughout the hardware’s life cycle.
  
Given this diversity of context and of types of systems engineered, and the wide range of stakeholders with whom they need to work, systems engineering workforce and culture should be at the forefront of DEI. In this way, we can represent as many aspects of the diverse community and their needs as possible within the team, and the diverse nature of the team also creates the innovation from which we can realise the best solutions.
+
Current methods for quantifying hardware assurance are adapted from the fields of quality and reliability engineering, which use methods like Failure Mode and Effects Analysis (FMEA). (SAE 2021) FMEA is semi-quantitative and combines probabilistic hardware failure data and input from experts. Adapting FMEA to quantify hardware assurance is hampered when it relies on assigning probabilities to human behavior that may be motivated by money, malicious intent, etc. Expert opinion often varies when quantifying and weighting factors used in generating risk matrices and scores. In response, recent efforts are attempting to develop quantitative methods that reduce subjectivity.
  
Like most of engineering, systems engineering was historically not practiced by a diverse group of people. Therefore, it is necessary to apply the notions of equity (as defined) in order to ensure that the widest range of people are enabled and empowered to become and develop as systems engineers.
+
Game theoretic analysis (game theory) is the creation of mathematical models of conflict and cooperation between intelligent and rational decision-makers. (Myerson 1991) Models include dynamic'','' as opposed to static, interactions between attackers and defenders that can quantify the risks associated with potential interactions among adversaries, hardware developers, and manufacturing processes. (Eames and Johnson 2017) Creation of the models forces one to define attack scenarios explicitly and to input detailed knowledge of hardware development and manufacturing processes. Outputs of the model may include a ranking of the most likely attacks to occur based on cost-benefit constraints on the attackers and defenders. (Graf 2017) The results can empower decision-makers to make quantitative trade-off decisions about hardware assurance.
  
Inclusion (as defined) is about ensuring that the whole (diverse) team is engaged, supported and feels safe and able to give of their best to the team’s activity. An inclusive team will produce increased productivity and better-quality outcomes than the alternative. It also provides increased potential for inclusive products because of the greater range of stakeholder views within the team.
+
Another quantification method that results in a confidence interval for detecting counterfeit/suspect microelectronics is presented in the SAE AS6171 standard. (SAE 2016) Confidence is based on knowing the types of defects associated with counterfeits, and the effectiveness of different tests to detect those defects. Along the same lines, a standard for hardware assurance might be developed to quantify the confidence interval by testing against a catalogue of known vulnerabilities, such as those documented in the MITRE Common Vulnerabilities and Exposures (CVE) list. (MITRE 2020)
  
==Inclusive Engineering==
+
Distributed ledger technology (DLT) is an example of an emerging technology that could enable a standardized approach for quantifying hardware assurance attributes such as data integrity, immutability, and traceability. DLT can be used in conjunction with manufacturing data (such as dimensional measurement, parametric testing, process monitoring, and defect mapping) to improve tamper resistance using component provenance and traceability data. DLT also enables new scenarios of cross-organizational data fusion, opening the door to new classes of hardware integrity checks.  
Inclusive Engineering (ref. 7) is the discipline of ensuring that engineering products and services are accessible to and inclusive of all users and are as free as possible from discrimination and bias. This should consider as far as possible all human differences (characteristics of diversity). It is a way of ensuring that engineering is appropriate, ethical, accessible, and as risk free as possible. The extent to which an engineered system is inclusive reduces the degree to which adaptation has to be applied to address the needs of people with differences e.g., differing vision, differing strength or motor functions.
 
  
In their enthusiasm for solutions engineers often do not stop to think about whether they have considered all of the things that impact on their design – and in particular all of the non-technical requirements that are not specified by the client or potential beneficiary. As a result, proposed solutions often lack the perspectives of people who have not been involved in their development – and in an industry which is notoriously lacking in diversity – this often means that they fail to include the perspectives of women, people with disabilities, the ageing population, and those with other under-represented characteristics.
+
==Manage Risks==
 +
The selection of specific components for use in subsystems and systems should be the outcome of performance-risk and cost-benefit trade-off assessments in their intended context of use. The goal of risk management and mitigation planning is to select mitigations with the best overall operational risk reduction and the lowest cost impact. The required level of hardware assurance varies with the criticality of a component's use and the system in which it is used.  
  
Figure 3 shows an inclusive engineering framework (ref. 8) which has eight elements, all of which are important factors for systems engineers to address even if the stated requirements do not cover them.  
+
During a typical development life cycle of a system – architecture, design, code, and implementation – various types of problems can pose risks to the operational functionality of the hardware components provided. These risks include weaknesses or defects that are inadvertent (unintentional), as well as counterfeits that may be either inadvertent or intentionally injected into the supply chain for financial motivations or malicious components designed to change functionality.
  
'''Figure 3 Inclusive Engineering Framework'''
+
Managing risk in the context of hardware assurance seeks to decrease the risk of weaknesses that create attack surfaces that can be exploited, while improving confidence that an implementation resists exploitation. Ideally, risk management reduces risk and maximizes assurance to an acceptable level. Often, risks are considered in the context of likelihood of consequences and the costs and effectiveness of mitigations. However, new operationally impactful risks are recognized continuously over the hardware life cycle and supply chains of components. At the same time hardware weaknesses are often exploited through software or firmware. Therefore, to maximize assurance and minimize operationally impactful risks mitigation-in-depth across all constituent components must be considered. This highlights the need for a dynamic risk profile.
  
One way that systems engineers can maximise the potential for inclusive and sustainable solutions is to ensure that DEI considerations are through application of the ISO/IEC/IEEE 15288:2015 Technical Processes. Table 1 illustrates the application of Inclusive Engineering these processes.
+
An example of a post-manufacturing mitigation involves a new hardware risk identified during field operation. A dynamic risk profile can be used to characterize the issue and identify possible resources to address the suspect component function. This profile can also be used to track and address risks throughout its life, including obsolescence-related risk. One means of mitigating this kind of hardware life cycle risk is the use of existing programmable logic.
  
Table 1. Mapping of the application of ISO/IEC/IEEE 15288:2015 Technical Processes to Inclusive Engineering considerations.
+
Just as with software patches and updates, new attack surfaces on hardware may become exposed through the mitigation being applied, and they will likely take a long time to discover. In the example above, the programmable logic is updated to provide a new configuration to protect the hardware. In this context, access to hardware reconfiguration must be limited to authorized parties to prevent an unauthorized update that introduces weaknesses on purpose or by accident. While programmable logic may have mitigated a specific attack surface or type of weakness, additional mitigations are needed to minimize risk more completely. This is mitigation-in-depth – multiple mitigations building upon one another.
  
{|+'''Table 1. Mapping of the application of ISO/IEC/IEEE 15288:2015 Technical Processes to Inclusive Engineering considerations.'''
+
Throughout the entire supply chain, critical pieces of information can be inadvertently exposed. The exposure of such information directly enables the creation and exploitation of new attack surfaces. Therefore, the supply chain infrastructure must also be assessed for weaknesses, and the development, use, and maintenance of hardware components assured.  The dynamic risk profile offers a framework to balance mitigations in the context of risk and cost throughout the complete hardware and system life cycles.
|-
 
!'''ISO/IEC/IEEE 15288:2015 Technical Process'''
 
!'''Inclusive Engineering considerations'''
 
|-
 
|Business or Mission Analysis
 
|*Ensure all stakeholders are identified, both the obvious (beneficial) stakeholders, and those potentially affected by the system and the associated project (referred to as “unwilling” stakeholders).
 
|-
 
|Stakeholder Needs and Requirements Definition
 
|*Identify stated stakeholder needs and the unstated but necessary needs arising from inclusive design – e.g. access, language, disability.
 
*Use understanding of Sustainable Development Goals, circular economies etc. to inform future-looking discussions about needs.
 
|-
 
|System Requirements Definition
 
|*Ensure that inclusion considerations result in well-specified requirements drawing on standards and legislation as necessary.
 
*Ensure that definition of the System Boundary is informed by its intended and unintended emergent effects on its wider context.
 
*Facilitate careful trade-off and option analysis to optimise equitable outcomes.
 
|-
 
|Architecture Definition
 
|*Ensure that all necessary Architecture viewpoints are considered to ensure that inclusion and sustainability factors can be given due consideration.
 
*Ensure that Architectures are open to allow future technology adoption where beneficial during the system lifecycle.
 
|-
 
|Design Definition
 
|*Ensure that technology choices and principles for design evolution are informed by Sustainable Development Goals, circular economies etc.
 
|-
 
|System Analysis
 
|*Ensure that System Analysis includes the modelling and prediction of inclusive engineering and sustainable development factors, in particular modelling to understand key emergent outcomes.
 
|-
 
|Implementation
 
|*Ensure that the design team is diverse, properly trained, and understands the principles of diversity, equity, inclusion, sustainability, circular economy, etc.
 
|-
 
|Integration
 
|*Ensure that the integration process is safe, secure, and environmentally compliant.
 
|-
 
|Verification
 
|*Ensure that planned verification activities fully address all aspects of diversity, equity, and inclusion for all relevant stakeholders and are safe, secure, and environmentally compliant.
 
|-
 
|Transition
 
|*Ensure that transition plans fully cover all stakeholders and are safe, secure, and environmentally compliant, and that any temporary/transitional arrangements do not have accidental negative effects on unwilling stakeholders or the natural environment i.e., there is an equitable transition plan.
 
|-
 
|Validation
 
|*Ensure that that planned validation activities fully address all aspects of diversity, equity, and inclusion for all relevant stakeholders including indirect/unwilling stakeholders and the natural environment and are safe, secure, and environmentally compliant.
 
|-
 
|Operations
 
|*Ensure that selection and training for operations staff is sufficient that a diverse group of operators can correctly operate all aspects of the system such that the system remains safe, secure, and environmentally compliant.
 
|-
 
|Maintenance
 
|*Ensure that selection and training for maintenance staff is sufficient that a diverse group of maintainers can correctly operate all aspects of the system such that the system remains safe, secure, and environmentally compliant.
 
*Ensure that planned maintenance ensures that the system fully meets its initial specification throughout its service life e.g., energy use, emissions, pollution.
 
|-
 
|Disposal
 
|*Ensure that selection and training for disposal staff is sufficient that a diverse group of staff can correctly dispose of hazardous materials such that the system remains safe, secure, and environmentally compliant.
 
*Ensure that disposal of hazardous materials is carefully planned, and that recycling and reuse opportunities are maximised.
 
|}
 
  
 
==References==
 
==References==
 +
 
===Works Cited===
 
===Works Cited===
ABET. 2020. "Diversity, Equity, and Inclusion." Accrediting Board for Engineering and Technology (ABET) website. https://www.abet.org/about-abet/diversity-equity-and-inclusion/ Accessed 31 Dec 2020.
+
Eames, B.K. and M.H. Johnson. 2017. “Trust Analysis in FPGA-based Systems.” Proceeding of GOMACTech 2017, March 20-23, 2017, Reno, NV.
  
Harding, A. and A. Pickard. "Towards a more Diverse INCOSE." INCOSE INSIGHT Practitioner Magazine. 22(3). Oct 2019.
+
Graf, J. 2017. “OpTrust: Software for Determining Optimal Test Coverage and Strategies for Trust.” Proceedings of GOMACTech 2017, March 20-23, 2017, Reno, NV.
  
Royal Academy of Engineering. 2015. “Increasing Diversity and Inclusion in Engineering–A Case Study Toolkit.” Case study, Royal Academy of Engineering. https://www.raeng.org.uk/policy/diversity-in-engineering/diversity-inclusion-toolkit-re-sources/documents/increasing-diversity-and-inclusion-in-engi-neering.
+
Martin, R.A. 2014. “Non-Malicious Taint: Bad Hygiene is as Dangerous to the Mission as Malicious Intent.” CrossTalk Magazine''.'' 27(2).
  
Hunt, V., S. Prince, S. Dixon­Fyle, and L. Yee. 2018. “Delivering Through Diversity.” Report, Mckinsey & Company. https://www.mckinsey.com/~/media/McKinsey/Business%20Functions/Organization/Our%20Insights/Delivering%20through%20diversity/Delivering-through-diversity_full-report.ashx
+
MITRE. 2020. “Common Vulnerabilities and Exposures.” Accessed March 31, 2021. Last Updated December 11, 2020. Available: https://cve.mitre.org/cve/
  
National Academy of Engineering. 2002. "Diversity in En­gineering: Managing the Workforce of the Future." Wash­ington, DC: The National Academies Press. https://doi.org/10.17226/10377
+
Myerson, R.R. 1991. ''Game Theory: Analysis of Conflict''.  Cambridge, MA: Harvard University Press.
  
INCOSE. 2020. "Definition of systems engineering." https://www.incose.org/about-systems-engineering/about-systems-engineering Accessed 31 Dec 2020.
+
NIST. 2020. Roots of Trust. Accessed March 31, 2021. Last Updated June 22, 2020. Available: https://csrc.nist.gov/projects/hardware-roots-of-trust
  
Inclusive Engineering downloaded 31 Dec 2020 http://www.inceng.org/  
+
Oberg, J. 2020. Reducing Hardware Security Risk. Accessed March 31, 2021. Last Updated July 1, 2020. Available: https://semiengineering.com/reducing-hardware-security-risk/
  
Inclusive Engineering framework downloaded 31 Dec 2020 http://www.inceng.org/inclusive-engineering-framework.html
+
SAE. 2016. SAE AS6171, ''Test Methods Standard: General Requirements, Suspect/Counterfeit, Electrical, Electronic, and Electromechanical Parts.'' SAE International. Accessed March 31, 2021. Available: https://www.sae.org/standards/content/as6171/
 +
 
 +
SAE. 2021. SAE J1739_202101, ''Potential Failure Mode and Effects Analysis (FMEA) Including Design FMEA'', ''Supplemental FMEA-MSR, and Process FMEA.'' SAE International. Accessed March 31, 2021. Last Updated January 13, 2021. Available: https://www.sae.org/standards/content/j1739_202101/
  
 
===Primary References===
 
===Primary References===
None.
+
Bhunia, S. and M. Tehranipoor. 2018. ''[[Hardware Security: A Hands-on Learning Approach]]''. Amsterdam, Netherlands: Elsevier Science.
 +
 
 +
ENISA. 2017. ''[[Hardware Threat Landscape and Good Practice Guide. Final Version 1.0]]''. European Union Agency for Cybersecurity. Accessed March 31, 2021. Available: https://www.enisa.europa.eu/publications/hardware-threat-landscape
 +
 
 +
TAME Steering Committee. 2019. ''[[Trusted and Assured Microelectronics Forum Working Group Reports]]''. Accessed March 31, 2021. Last Updated December 2019. Available: https://dforte.ece.ufl.edu/wp-content/uploads/sites/65/2020/08/TAME-Report-FINAL.pdf
  
 
===Additional References===
 
===Additional References===
None.
+
DARPA. A DARPA Approach to Trusted Microelectronics. Accessed March 31, 2021. Available: [https://www.darpa.mil//about-us/darpa-approach-to-trusted-microelectronics https://www.darpa.mil/attachments/Background_FINAL3.pdf]
 +
 
 +
Fazzari, S. and R. Narumi. 2019. ''New & Old Challenges for Trusted and Assured Microelectronics''. Accessed March 31, 2021. Available: https://apps.dtic.mil/dtic/tr/fulltext/u2/1076110.pdf
 +
 
 +
IEEE. 2008-2020. IEEE International Symposium on Hardware Oriented Security and Trust (HOST). Annual symposium held since 2008 providing wealth of articles on hardware assurance.
 +
 
 +
Martin, R. 2019. "Hardware Assurance and Weakness Collaboration and Sharing (HAWCS)." Proceedings of the 2019 Software and Supply Chain Assurance Forum, September 17-18, 2019 in McLean, VA. Accessed March 31, 2021. Available: https://csrc.nist.gov/CSRC/media/Projects/cyber-supply-chain-risk-management/documents/SSCA/Fall_2019/WedPM2.2_Robert_Martin.pdf
 +
 
 +
NDIA. 2017. Trusted Microelectronics Joint Working Group: Team 3 White Paper: Trustable Microelectronics Standard Products. Accessed March 31, 2021. Available: https://www.ndia.org/-/media/sites/ndia/divisions/working-groups/tmjwg-documents/ndia-tm-jwg-team-3-white-paper-finalv3.ashx
 +
 
 +
Regenscheid, A. 2019. NIST SP 800-193, ''Platform Firmware Resiliency Guidelines''. Accessed March 31, 2021. Available: https://csrc.nist.gov/publications/detail/sp/800-193/final
  
 +
Ross, R., V. Pillitteri, R. Graubart, D. Bodeau, R. McQuaid. 2019. NIST SP 800-160 Vol. 2, ''Developing Cyber Resilient Systems – A Systems Security Engineering Approach''. Accessed March 31, 2021. Available: https://csrc.nist.gov/News/2019/sp-800-160-vol2-developing-cyber-resilient-systems
 
----
 
----
<center>[[Team Dynamics|< Previous Article]] | [[Enabling Teams|Parent Article]] | [[Technical Leadership in Systems Engineering|Next Article >]]</center>
+
<center>[[System Affordability|< Previous Article]] | [[Systems Engineering and Quality Attributes|Parent Article]] | [[System Reliability, Availability, and Maintainability|Next Article >]]</center>
  
 
<center>'''SEBoK v. 2.4, released 19 May 2021'''</center>
 
<center>'''SEBoK v. 2.4, released 19 May 2021'''</center>
  
[[Category:Part 5]]
+
[[Category: Part 6]]
 
[[Category:Topic]]
 
[[Category:Topic]]
[[Category:Enabling Teams]]
+
[[Category:Systems Engineering and Quality Attributes]]

Revision as of 12:48, 17 August 2021


Authors: Michael Bear, Donald Davidson, Shawn Fetterolf, Darin Leonhardt, Daniel Radack, Karen Johnson, Elizabeth A. McDaniel Contributors: Michael Berry, Brian Cohen, Diganta Das, Houman Homayoun, Thomas McDermott


This article describes the discipline of hardware assurance, especially as it relates to systems engineering. It is part of the SE and Quality Attributes Knowledge Area.

Overview

System hardware assuranceSystem hardware assurance is a set of system security engineering activities (see System Security for more information) undertaken to quantify and increase the confidence that electronics function as intended and only as intended throughout their life cycle, and to manage identified risks. The term hardware refers to electronic components, sometimes called integrated circuits or chips. As products of multi-stage processes involving design, manufacturing and post-manufacturing, packaging, and test, they must function properly under a wide range of circumstances. Hardware components – alone and integrated into subcomponents, subsystems, and systems – have weaknesses and vulnerabilities enabling exploitation. Weaknesses are flaws, bugs, or errors in design, architecture, code, or implementation. Vulnerabilities are weaknesses that are exploitable in the context of use (Martin 2014).

Hardware assurance is conducted to minimize risks related to hardware that can enable adversarial exploitation and subversion of functionality, counterfeit production, and loss of technological advantage.  Challenges include increasing levels of sophistication and complexity of hardware architectures, integrated circuits, operating systems, and application software, combined with supply chain risks, emergence of new attack surfaces, and reliance on global sources for some components and technologies.

After identifying concerns and applicable mitigations, hardware assurance offers a range of possible activities and processes. At the component level, hardware assurance focuses on the hardware itself and the supply chain used to design and manufacture it; at the subcomponent, subsystems, and system levels, hardware assurance incorporates the software and firmware integrated with the component.

Engineering efforts to enhance trust in hardware have increased in response to complex hardware architectures, the increasing sophistication of adversarial attacks on hardware, and globalization of supply chains. These factors raise serious concerns about the security, confidentiality, integrity, and availability as well as the provenance and authenticity of hardware. The “root of trust” (NIST 2020) of a system is typically contained in the processes, steps, and layers of hardware components and across the systems engineering development cycle. System hardware assurance focuses on hardware components and their interconnections with software and firmware to reduce risks to proper function or other compromises of the hardware throughout the complete life cycle of components and systems. Advances in hardware assurance tools and techniques will strengthen designs, and enhance assurance during manufacturing, packaging, test, and deployment and operational use.

Life Cycle Concerns of Hardware Components

Hardware assurance should be applied at various stages of a component’s life cycle from hardware architecture and design, through manufacturing and testing, and finally throughout its inclusion in a larger system. The need for hardware assurance then continues throughout its operational life including sustainment and disposal.

As semiconductor technology advances the complexity of electronic components, it increases the need to “bake-in” assurance. Risks created during architecture, design, and manufacturing are challenging to address during the operational phase. Risks associated with interconnections between and among chips are also a concern. Therefore, improving a hardware assurance posture must occur as early as possible in the life cycle, thereby reducing the cost and schedule impacts associated with “fixing” components later in the life cycle of the system.

A conceptual overview of the typical hardware life cycle (Figure 1) illustrates the phases of the life cycle of components, as well as the subsystems and systems in which they operate. In each phase multiple parties and processes contribute a large set of variables and corresponding attack surfaces. As a result, the potential exists for compromise of the hardware as well as the subcomponents and systems in which they operate; therefore, matching mitigations should be applied at the time the risks are identified.

Figure 1. Component Life Cycle. (SEBoK Original)

Both the value of the hardware component and the associated cost of mitigating risks increase at each stage of the life cycle. Therefore, it is important to identify and mitigate vulnerabilities as early as possible. It takes longer to find and fix defects later, thereby increasing the complexity of replacing hardware with “corrected” designs that create system integration issues. In addition to cost savings, early correction and mitigation avoid delays in creating an operational system. It is essential to re-assess risks associated with hardware components throughout the life cycle periodically, especially as operational conditions change.

Hardware assurance during system sustainment is a novel challenge given legacy hardware and designs with their associated supply chains. In long-lived high-reliability systems, hardware assurance issues are compounded by obsolescence and diminished sourcing of components, thereby increasing concerns related to counterfeits and acquisitions from the gray market.  

Function as Intended and Only as Intended

Exhaustive testing can check system functions against specifications and expectations; however, checking for unintended functions is problematic. Consumers have a reasonable expectation that a purchased product will perform as advertised and function properly (safely and securely, under specified conditions) – but consumers rarely consider if additional functions are built into the product. For example, a laptop with a web-conferencing capability comes with a webcam that will function properly when enabled, but what if the webcam also functions when turned off, thereby violating expectations of privacy? Given that a state-of-the-art semiconductor component might have billions of transistors, “hidden” functions might be exploitable by adversaries. The statement “function as intended and only intended” communicates the need to check for unintended functions.

Hardware specifications and information in the design phase are needed to validate that components function properly to support systems or missions. If an engineer creates specifications that support assurance that flow down the system development process, the concept of “function as intended” can be validated for the system and mission through accepted verification and validation processes. “Function only as intended” is also a consequence of capturing the requirements and specifications to assure the product is designed and developed without extra functionality. For example, a Field Programmable Gate Array (FPGA) contains programmable logic that is highly configurable; however, the programmable circuitry might be susceptible to exploitation.

Given the specifications of a hardware component, specialized tools and processes can be used to determine with a high degree of confidence whether the component’s performance meets specifications. Research efforts are underway to develop robust methods to validate that a component does not have capabilities that threaten assurance or that are not specified in the original design. Although tools and processes can test for known weaknesses, operational vulnerabilities, and deviations from expected performance, all states of possible anomalous behavior cannot currently be determined or predicted.

Data and information can be used to validate the component’s function and should be collected from multiple sources including designers, developers, and members of the user community. Designers and developers can provide deep understanding of the component’s intended function and provide tests used to verify its functional performance before fielding. The merging of component design and development information with extensive field data, including third-party evaluation, contribute to assurance that the component is performing specified functions and that no unintended functionality is observed. 

Risks to Hardware

Modern systems depend on complex microelectronics, but advances in hardware without attention to associated risks can expose critical systems, their information, and the people who rely on them. “Hardware is evolving rapidly, thus creating fundamentally new attack surfaces, many of which will never be entirely secured”. (Oberg 2020)  Therefore, it is imperative that risk be modeled through a dynamic risk profile and be mitigated in depth across the entire profile. Hardware assurance requires extensible mitigations and strategies that can and do evolve as threats do. Hardware assurance methods seek to quantify and improve confidence that weaknesses that can become vulnerabilities that create risks are mitigated.

Most hardware components are commercially designed, manufactured, and inserted into larger assemblies by multi-national companies with global supply chains. Understanding the provenance and participants in complex global supply chains is fundamental to assessing risks associated with the components.

Operational risks that derive from unintentional or intentional features are differentiated based on the source of the feature. Three basic operational risk areas related to goods, products, or items are: failure to meet quality standards, maliciously tainted goods, and counterfeit hardware. Counterfeits are usually offered as legitimate products, but they are not. They may be refurbished or mock items made to appear as originals, re-marked products, the result of overproduction, or substandard production parts rejected by the legitimate producer. Counterfeit risks and substandard quality offer avenues for malware insertion and potential impacts to overall system performance and availability.

Failure to follow quality standards including safety and security standards, especially in design, can result in unintentional features or flaws being inadvertently introduced. These can occur through mistakes, omissions, or lack of understanding how features might be manipulated by future users for nefarious purposes. Features introduced intentionally for specific purposes can also make the hardware susceptible to espionage or control of the hardware at some point in its life cycle.

Quantify and Improve Confidence  

The quantification of hardware assurance is a key technical challenge because of the complex interplay among designer, manufacturer and supply chains, and adversarial intent, as well as the challenge of defining “security” with respect to hardware function. Quantification is necessary to identify and manage hardware risks within program budgets and timeframes. It enables a determination of the required level of hardware assurance and whether quantification is achievable throughout the hardware’s life cycle.

Current methods for quantifying hardware assurance are adapted from the fields of quality and reliability engineering, which use methods like Failure Mode and Effects Analysis (FMEA). (SAE 2021) FMEA is semi-quantitative and combines probabilistic hardware failure data and input from experts. Adapting FMEA to quantify hardware assurance is hampered when it relies on assigning probabilities to human behavior that may be motivated by money, malicious intent, etc. Expert opinion often varies when quantifying and weighting factors used in generating risk matrices and scores. In response, recent efforts are attempting to develop quantitative methods that reduce subjectivity.

Game theoretic analysis (game theory) is the creation of mathematical models of conflict and cooperation between intelligent and rational decision-makers. (Myerson 1991) Models include dynamic, as opposed to static, interactions between attackers and defenders that can quantify the risks associated with potential interactions among adversaries, hardware developers, and manufacturing processes. (Eames and Johnson 2017) Creation of the models forces one to define attack scenarios explicitly and to input detailed knowledge of hardware development and manufacturing processes. Outputs of the model may include a ranking of the most likely attacks to occur based on cost-benefit constraints on the attackers and defenders. (Graf 2017) The results can empower decision-makers to make quantitative trade-off decisions about hardware assurance.

Another quantification method that results in a confidence interval for detecting counterfeit/suspect microelectronics is presented in the SAE AS6171 standard. (SAE 2016) Confidence is based on knowing the types of defects associated with counterfeits, and the effectiveness of different tests to detect those defects. Along the same lines, a standard for hardware assurance might be developed to quantify the confidence interval by testing against a catalogue of known vulnerabilities, such as those documented in the MITRE Common Vulnerabilities and Exposures (CVE) list. (MITRE 2020)

Distributed ledger technology (DLT) is an example of an emerging technology that could enable a standardized approach for quantifying hardware assurance attributes such as data integrity, immutability, and traceability. DLT can be used in conjunction with manufacturing data (such as dimensional measurement, parametric testing, process monitoring, and defect mapping) to improve tamper resistance using component provenance and traceability data. DLT also enables new scenarios of cross-organizational data fusion, opening the door to new classes of hardware integrity checks.  

Manage Risks

The selection of specific components for use in subsystems and systems should be the outcome of performance-risk and cost-benefit trade-off assessments in their intended context of use. The goal of risk management and mitigation planning is to select mitigations with the best overall operational risk reduction and the lowest cost impact. The required level of hardware assurance varies with the criticality of a component's use and the system in which it is used.  

During a typical development life cycle of a system – architecture, design, code, and implementation – various types of problems can pose risks to the operational functionality of the hardware components provided. These risks include weaknesses or defects that are inadvertent (unintentional), as well as counterfeits that may be either inadvertent or intentionally injected into the supply chain for financial motivations or malicious components designed to change functionality.

Managing risk in the context of hardware assurance seeks to decrease the risk of weaknesses that create attack surfaces that can be exploited, while improving confidence that an implementation resists exploitation. Ideally, risk management reduces risk and maximizes assurance to an acceptable level. Often, risks are considered in the context of likelihood of consequences and the costs and effectiveness of mitigations. However, new operationally impactful risks are recognized continuously over the hardware life cycle and supply chains of components. At the same time hardware weaknesses are often exploited through software or firmware. Therefore, to maximize assurance and minimize operationally impactful risks mitigation-in-depth across all constituent components must be considered. This highlights the need for a dynamic risk profile.

An example of a post-manufacturing mitigation involves a new hardware risk identified during field operation. A dynamic risk profile can be used to characterize the issue and identify possible resources to address the suspect component function. This profile can also be used to track and address risks throughout its life, including obsolescence-related risk. One means of mitigating this kind of hardware life cycle risk is the use of existing programmable logic.

Just as with software patches and updates, new attack surfaces on hardware may become exposed through the mitigation being applied, and they will likely take a long time to discover. In the example above, the programmable logic is updated to provide a new configuration to protect the hardware. In this context, access to hardware reconfiguration must be limited to authorized parties to prevent an unauthorized update that introduces weaknesses on purpose or by accident. While programmable logic may have mitigated a specific attack surface or type of weakness, additional mitigations are needed to minimize risk more completely. This is mitigation-in-depth – multiple mitigations building upon one another.

Throughout the entire supply chain, critical pieces of information can be inadvertently exposed. The exposure of such information directly enables the creation and exploitation of new attack surfaces. Therefore, the supply chain infrastructure must also be assessed for weaknesses, and the development, use, and maintenance of hardware components assured.  The dynamic risk profile offers a framework to balance mitigations in the context of risk and cost throughout the complete hardware and system life cycles.

References

Works Cited

Eames, B.K. and M.H. Johnson. 2017. “Trust Analysis in FPGA-based Systems.” Proceeding of GOMACTech 2017, March 20-23, 2017, Reno, NV.

Graf, J. 2017. “OpTrust: Software for Determining Optimal Test Coverage and Strategies for Trust.” Proceedings of GOMACTech 2017, March 20-23, 2017, Reno, NV.

Martin, R.A. 2014. “Non-Malicious Taint: Bad Hygiene is as Dangerous to the Mission as Malicious Intent.” CrossTalk Magazine. 27(2).

MITRE. 2020. “Common Vulnerabilities and Exposures.” Accessed March 31, 2021. Last Updated December 11, 2020. Available: https://cve.mitre.org/cve/

Myerson, R.R. 1991. Game Theory: Analysis of Conflict.  Cambridge, MA: Harvard University Press.

NIST. 2020. Roots of Trust. Accessed March 31, 2021. Last Updated June 22, 2020. Available: https://csrc.nist.gov/projects/hardware-roots-of-trust

Oberg, J. 2020. Reducing Hardware Security Risk. Accessed March 31, 2021. Last Updated July 1, 2020. Available: https://semiengineering.com/reducing-hardware-security-risk/

SAE. 2016. SAE AS6171, Test Methods Standard: General Requirements, Suspect/Counterfeit, Electrical, Electronic, and Electromechanical Parts. SAE International. Accessed March 31, 2021. Available: https://www.sae.org/standards/content/as6171/

SAE. 2021. SAE J1739_202101, Potential Failure Mode and Effects Analysis (FMEA) Including Design FMEA, Supplemental FMEA-MSR, and Process FMEA. SAE International. Accessed March 31, 2021. Last Updated January 13, 2021. Available: https://www.sae.org/standards/content/j1739_202101/

Primary References

Bhunia, S. and M. Tehranipoor. 2018. Hardware Security: A Hands-on Learning Approach. Amsterdam, Netherlands: Elsevier Science.

ENISA. 2017. Hardware Threat Landscape and Good Practice Guide. Final Version 1.0. European Union Agency for Cybersecurity. Accessed March 31, 2021. Available: https://www.enisa.europa.eu/publications/hardware-threat-landscape

TAME Steering Committee. 2019. Trusted and Assured Microelectronics Forum Working Group Reports. Accessed March 31, 2021. Last Updated December 2019. Available: https://dforte.ece.ufl.edu/wp-content/uploads/sites/65/2020/08/TAME-Report-FINAL.pdf

Additional References

DARPA. A DARPA Approach to Trusted Microelectronics. Accessed March 31, 2021. Available: https://www.darpa.mil/attachments/Background_FINAL3.pdf

Fazzari, S. and R. Narumi. 2019. New & Old Challenges for Trusted and Assured Microelectronics. Accessed March 31, 2021. Available: https://apps.dtic.mil/dtic/tr/fulltext/u2/1076110.pdf

IEEE. 2008-2020. IEEE International Symposium on Hardware Oriented Security and Trust (HOST). Annual symposium held since 2008 providing wealth of articles on hardware assurance.

Martin, R. 2019. "Hardware Assurance and Weakness Collaboration and Sharing (HAWCS)." Proceedings of the 2019 Software and Supply Chain Assurance Forum, September 17-18, 2019 in McLean, VA. Accessed March 31, 2021. Available: https://csrc.nist.gov/CSRC/media/Projects/cyber-supply-chain-risk-management/documents/SSCA/Fall_2019/WedPM2.2_Robert_Martin.pdf

NDIA. 2017. Trusted Microelectronics Joint Working Group: Team 3 White Paper: Trustable Microelectronics Standard Products. Accessed March 31, 2021. Available: https://www.ndia.org/-/media/sites/ndia/divisions/working-groups/tmjwg-documents/ndia-tm-jwg-team-3-white-paper-finalv3.ashx

Regenscheid, A. 2019. NIST SP 800-193, Platform Firmware Resiliency Guidelines. Accessed March 31, 2021. Available: https://csrc.nist.gov/publications/detail/sp/800-193/final

Ross, R., V. Pillitteri, R. Graubart, D. Bodeau, R. McQuaid. 2019. NIST SP 800-160 Vol. 2, Developing Cyber Resilient Systems – A Systems Security Engineering Approach. Accessed March 31, 2021. Available: https://csrc.nist.gov/News/2019/sp-800-160-vol2-developing-cyber-resilient-systems


< Previous Article | Parent Article | Next Article >
SEBoK v. 2.4, released 19 May 2021