NIST SP 800-160 Vol. 1 Rev. 1 日本語訳

NIST Special Publication NIST SP 800-160v1r1

Ron Ross

Mark Winstead

Michael McEvilley

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-160v1r1

NIST Special Publication NIST SP 800-160v1r1

Ron Ross

Computer Security Division Information Technology Laboratory

Mark Winstead

Michael McEvilley

The MITRE Corporation

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-160v1r1

November 2022

U.S. Department of Commerce Gina M. Raimondo, Secretary

National Institute of Standards and Technology Laurie E. Locascio, NIST Director and Under Secretary of Commerce for Standards and Technology

Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately. Such identification is not intended to imply recommendation or endorsement by the National Institute of Standards and Technology (NIST), nor is it intended to imply that the entities, materials, or equipment are necessarily the best available for the purpose. There may be references in this publication to other publications currently under development by NIST in accordance with its assigned statutory responsibilities. The information in this publication, including concepts and methodologies, may be used by federal agencies even before the completion of such companion publications. Thus, until each publication is completed, current requirements, guidelines, and procedures, where they exist, remain operative. For planning and transition purposes, federal agencies may wish to closely follow the development of these new publications by NIST. Organizations are encouraged to review all draft publications during public comment periods and provide feedback to NIST. Many NIST cybersecurity publications, other than the ones noted above, are available at https://csrc.nist.gov/publications.

Authority This publication has been developed by NIST in accordance with its statutory responsibilities under the Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3551 et seq., Public Law (P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130.

Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce under statutory authority. Nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other federal official. This publication may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright in the United States. Attribution would, however, be appreciated by NIST.

NIST Technical Series Policies Copyright, Fair Use, and Licensing Statements NIST Technical Series Publication Identifier Syntax

Publication History Approved by the NIST Editorial Review Board on 2022-11-08 Supersedes NIST SP 800-160 Vol. 1 (Nov. 2016; updated 2018-03-21) https://doi.org/10.6028/NIST.SP.800-160v1

How to Cite this NIST Technical Series Publication: Ross R, McEvilley M, Winstead M (2022) Engineering Trustworthy Secure Systems. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-160v1r1. https://doi.org/10.6028/NIST.SP.800-160v1r1

Author ORCID iDs Ron Ross: 0000-0002-1099-9757

Contact Information security-engineering@nist.gov National Institute of Standards and Technology Attn: Computer Security Division, Information Technology Laboratory 100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930

All comments are subject to release under the Freedom of Information Act (FOIA).

This publication describes a basis for establishing principles, concepts, activities, and tasks for engineering trustworthy secure systems. Such principles, concepts, activities, and tasks can be effectively applied within systems engineering efforts to foster a common mindset to deliver security for any system, regardless of the system’s purpose, type, scope, size, complexity, or the stage of its system life cycle. The intent of this publication is to advance systems engineering in developing trustworthy systems for contested operational environments (generally referred to as systems security engineering) and to serve as a basis for developing educational and training programs, professional certifications, and other assessment criteria.

assurance; developmental engineering; engineering trades; field engineering; implementation; information security; information security policy; inspection; integration; penetration testing; protection needs; requirements analysis; resilience; review; risk assessment; risk management; risk treatment; security architecture; security design; security requirements; specifications; stakeholders; system of systems; system component; system element; system life cycle; systems; systems engineering; systems security engineering; trustworthiness; validation; verification

The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analyses to advance the development and productive use of information technology. ITL’s responsibilities include the development of management, administrative, technical, and physical standards and guidelines for the cost-effective security and privacy of other than national security-related information in federal information systems. The Special Publication 800-series reports on ITL’s research, guidelines, and outreach efforts in information system security, and its collaborative activities with industry, government, and academic organizations.

NOTICE: ITL has requested that holders of patent claims whose use may be required for compliance with the guidance or requirements of this publication disclose such patent claims to ITL. However, holders of patents are not obligated to respond to ITL calls for patents and ITL has not undertaken a patent search in order to identify which, if any, patents may apply to this publication.

As of the date of publication and following call(s) for the identification of patent claims whose use may be required for compliance with the guidance or requirements of this publication, no such patent claims have been identified to ITL.

No representation is made or implied by ITL that licenses are not required to avoid patent infringement in the use of this publication.

This publication should be used as a supplement to International Standard ISO/IEC/IEEE 15288 and other supporting international standards. It is recommended that organizations using this publication obtain the appropriate international standards to understand the context of the material in Appendices G through K. Content from ISO/IEC/IEEE 15288 referenced in this publication is used with permission from the Institute of Electrical and Electronics Engineers. It is noted as follows:

Reprinted with permission from IEEE, Copyright IEEE 2015, All rights reserved.

The reprinted material has been updated to reflect any changes in the international standard.

On May 12, 2021, the President signed an Executive Order (EO) on Improving the Nation’s Cybersecurity [1]. The Executive Order stated,

The United States faces persistent and increasingly sophisticated malicious cyber campaigns that threaten the public sector, the private sector, and ultimately the American people’s security and privacy. The Federal Government must improve its efforts to identify, deter, protect against, detect, and respond to these actions and actors.

The Executive Order further described the holistic nature of the cybersecurity challenges confronting the Nation with computing technology embedded in every type of system from general-purpose computing systems that support businesses to cyber-physical systems that control the operations in power plants and provide electricity to the American people. The Federal Government must bring the full scope of its authorities and resources to bear in order to protect and secure its computer systems, whether the systems are cloud-based, on-premises, or hybrid. The scope of protection and security must include systems that process data (i.e., information technology [IT]) and systems that run the machinery that ensure our safety (i.e., operational technology [OT]).

In response to the EO, there is a need to:

Building trustworthy, secure systems cannot occur in a vacuum with stovepipes for software, hardware, information technology, and the human element (e.g., designers, operators, users, attackers of these systems). Rather, it requires a transdisciplinary approach to protection, a determination across all assets where loss could occur, and an understanding of adversity, including how adversaries attack and compromise systems. As such, this publication addresses considerations for the engineering-driven actions necessary to develop defensible and survivable systems, including the components that compose and the services that depend on those systems. The objective is to address security issues from the perspective of stakeholder requirements and protection needs and to use established engineering processes to ensure that such requirements and needs are addressed with appropriate fidelity and rigor across the entire life cycle of the system.

Engineering trustworthy, secure systems is a significant undertaking that requires a substantial investment in the requirements, architecture, and design of systems, components, applications, and networks. A trustworthy system provides compelling evidence to support claims that it meets its requirements to deliver the protection and performance needed by stakeholders. Introducing a disciplined, structured, and standards-based set of systems security engineering activities and tasks provides an important starting point and forcing function to initiate needed change.

“Providing satisfactory security controls in a computer system is in itself a system design problem. A combination of hardware, software, communications, physical, personnel and administrative-procedural safeguards is required for comprehensive security. In particular, software safeguards alone are not sufficient.”

“Security Controls for Computer Systems,” (The Ware Report), Rand Corporation Defense Science Board Task Force on Computer Security, February 1970

“Mission assurance requires systems that behave with predictability and proportionality.”

General Michael Hayden Former Director National Security Agency (NSA) and Central Intelligence Agency (CIA) Syracuse University, October 2009

“In the past, it has been assumed that to show that a system is safe, it is sufficient to provide assurance that the process for identifying the hazards has been as comprehensive as possible, and that each identified hazard has one or more associated controls. While historically this approach has been used reasonably effectively to ensure that known risks are controlled, it has become increasingly apparent that evolution to a more holistic approach is needed as systems become more complex and the cost of designing, building, and operating them become more of an issue.”

Preface, National Aeronautics and Space Administration (NASA) System Safety Handbook, Volume 1, November 2011

“This whole economic boom in cybersecurity seems largely to be a consequence of poor engineering.”

Carl Landwehr Communications of the Association for Computing Machinery (ACM), February 2015

“Cybersecurity requires more than government action. Protecting our Nation from malicious cyber actors requires the Federal Government to partner with the private sector. The private sector must adapt to the continuously changing threat environment, ensure its products are built and operate securely, and partner with the Federal Government to foster a more secure cyberspace…Incremental improvements will not give us the security we need; instead, the Federal Government needs to make bold changes and significant investments in order to defend the vital institutions that underpin the American way of life.”

Executive Order (EO) on Improving the Nation’s Cybersecurity, May 2021

“[Systems] security engineering must be fundamental to systems engineering, not just a specialty discipline. Security concepts must be fundamental to [an] engineering education, and security proficiency must be fundamental in development teams. Security fundamentals must be clearly understood by stakeholders and effectively evaluated in a way that considers broad goals with security functions and outcomes.”

Security in the Future of Systems Engineering (FuSE), a Roadmap of Foundational Concepts, INCOSE International Symposium, July 2021

The authors gratefully acknowledge and appreciate the significant contributions from individuals and organizations in the public and private sectors whose constructive comments improved the overall quality, thoroughness, and usefulness of this publication. In particular, we wish to thank Jeff Brewer, Ken Cureton, Jordan Denmark, Rick Dove, Holly Dunlap, Jim Foti, Michael Hankins, Daryl Hild, M. Lee, Tom Llanso, Jimmie McEver, Perri Nejib, Cory Ocker, Daniel Patrick Pereira, Victoria Pillitteri, Greg Ritter, Thom Schoeffling, Theresa Soloway, Nick Stegman, Gary Stoneburner, Gregory Touhill, Isabel Van Wyk, Adam Williams, Drew Wilson, Carol Woody, William Young, and Michael Zisa. The authors also wish to acknowledge members of the International Council for Systems Engineering (INCOSE), including members of the Systems Security Engineering and the Resilient Systems Working Groups, for numerous discussions on the content of the document. Finally, the authors wish to thank the students participating in INCOSE tutorials and MITRE Systems Security Engineering courses whose comments and valuable insights helped to guide and inform many of the proposed changes in this publication.

Historical Contributions The authors gratefully acknowledge the contributions of Janet Carrier Oren, one of the original authors of NIST Special Publication 800-160, Volume 1. The authors also wish to acknowledge the following organizations and individuals for their historic contributions to this publication: Organizations: National Security Agency; Naval Postgraduate School; Department of Defense Office of Acquisition, Technology, and Logistics; Department of Homeland Security Science and Technology Office, Cyber Security Division; International Council on Systems Engineering; United States Air Force; Air Force Institute of Technology; Northrop Grumman Corporation; The MITRE Corporation; The Boeing Company; Lockheed Martin Corporation. Individuals: Beth Abramowitz, Max Allway, Kristen Baldwin, Dawn Beyer, Debora Bodeau, Paul Clark, Keesha Crosby, Judith Dahmann, Kelley Dempsey, Holly Dunlap, Jennifer Fabius, Daniel Faigin, Jeanne Firey, Robin Gandhi, Rich Graubart, Kevin Greene, Richard Hale, Daryl Hild, Kesha Hill, Danny Holtzman, Cynthia Irvine, Brett Johnson, Ken Kepchar, Stephen Khou, Alvi Lim, Logan Mailloux, Dennis Mangsen, Doug Maughn, Rosalie McQuaid, Joseph Merkling, John Miller, Thuy Nguyen, Perri Nejib, Lisa Nordman, Dorian Pappas, Paul Popick, Roger Schell, Thom Schoeffling, Matthew Scholl, Peter Sell, Gary Stoneburner, Glenda Turner, Edward Yakabovicz, and William Young. Finally, the authors respectfully acknowledge the seminal work in computer security that began in the 1960s. The vision, insights, and dedicated efforts of those early pioneers in computer security serve as the philosophical and technical foundation for the security principles, concepts, methods, and practices employed in this publication to address the critically important problem of engineering trustworthy secure systems.

“For the first few decades as a burgeoning discipline, cybersecurity has been dominated by the development of widgets to address some aspect of the problem. Systems have become increasingly complex and interconnected, creating even more attack opportunities, which in turn creates even more opportunities to create defensive widgets that will bring some value in detecting or preventing an aspect of the attack space. Eventually, this becomes a game of whack-a-mole in which a simulated mole pops up from one of many holes and the objective is to whack the mole before it pops back in its hole. The moles represent new attacks, and the holes represent a huge array of potential vulnerabilities – both known and as-yet-undiscovered.

Underlying [the discipline of] engineering is science. Sometimes engineering gets ahead of science, such as in bridge building, where the fundamentals of material science were not well understood. Many bridges were built; many fell down; some stayed up; designs of the ones that stayed up were copied. Eventually, for engineering to advance beyond some point, science must catch up with engineering. The science underlying cybersecurity [and more generally, security] engineering is complex and difficult. On the other hand, there is no time like the present to start, because it is both urgent and important to the future.…”

-- O. Sami Saydjari Engineering Trustworthy Systems McGraw-Hill, August 2018

When crossing a bridge, we have a reasonable expectation that the bridge will not collapse and will get us to our destination without incident. For bridge builders, the focus is on equilibrium, static and dynamic loads, vibrations, and resonance. The science of physics combines with civil engineering principles and concepts to produce a product that we deem trustworthy, giving us a level of confidence that the bridge is fit-for-purpose.

For system developers, there are also fundamental principles and concepts that can be found in mathematics, computer science, computer and electrical engineering, systems engineering, and software engineering that when properly employed, provide the necessary trustworthiness to engender that same level of confidence. Trustworthy secure systems are achieved by making a significant and substantial investment in strengthening the underlying systems and system components by employing transdisciplinary systems engineering efforts guided and informed by well-defined security requirements and secure architectures and designs. Such efforts have been proven over time to produce sound engineering-based solutions to complex and challenging systems security problems. Only under those circumstances can we build systems that are adequately secure and exhibit a level of trustworthiness that is sufficient for the purpose for which the system was built.

“Scientists study the world as it is, engineers create the world that never has been.”

Theodore von Kármán 1962 National Medal of Science Recipient

“To deliver system behavior, the systems engineer must define a group of subsystems and precisely how those subsystems are to interact with each other. It is the subsystems and their interactions which produce the system-level behavior. Many of us recognize a vehicle that can take a 60-degree curve at 200 miles per hour as possessing a valuable system behavior. Would we as quickly recognize safe, private, trusted, and available as system behaviors? These behaviors require the same careful system-level design and trades to achieve optimal solutions as the performance system behavior I mentioned above. And there is a clear need—investors want the system to keep their data private, to be safe, and to be trustworthy so that their control is not compromised by a cyber threat, and to be highly available.

If we systems engineers are willing to recognize these behaviors as system behaviors, then we are accountable for delivering them as part of our job. If we choose to view these behaviors as attributes of the parts of our system but not the system as a whole, then we are likely to consider them as jobs for the “specialty engineers.” I’ve looked back into past behaviors of our system engineering community. What I find are examples of systems engineers giving our ‘specialty engineering’ colleagues these challenges by way of the requirements-allocation process. I think we have been wrong to do this. Our “specialty” colleagues are likely to take these allocated requirements and focus on building safe, private, trusted, available parts of a system—rather than in delivering safe, private, trusted, and available system behaviors. It is true you can build a safer system by building safe parts. However, you can’t build a truly safe system without having safe parts interacting with each other in a safe manner. The same can be said for other system behaviors (private, trusted, available, and so on).”

-- John A. Thomas President, INCOSE INCOSE Insight, July 2013.

Today’s systems¹ are inherently complex. The growth in the size, number, and types of components and technologies² that compose those systems as well as the system dependencies result in a range of consequences from inconvenience to catastrophic loss due to adversity³ within the operating environment. Managing the complexity of trustworthy secure systems requires achieving the appropriate level of confidence in the feasibility, correctness-in-concept, philosophy, and design of a system to produce only the intended behaviors and outcomes. This provides the foundation to address stakeholder protection needs and security concerns with sufficient confidence that the system functions only as intended while subjected to different types of adversity and to realistically bound those expectations with respect to constraints and uncertainty. The failure to address complexity and security will leave the Nation susceptible to potentially serious, severe, or catastrophic consequences.

The term security is used in this publication to mean freedom from the conditions that can cause a loss of assets with unacceptable consequences.⁴ Stakeholders must define the scope of security in terms of the assets to which security applies and the consequences against which security is assessed.⁵ Systems engineering provides a foundation for a disciplined and structured approach to building assured, trustworthy secure systems. As a systems engineering subdiscipline, systems security engineering addresses security-relevant considerations intended to produce secure outcomes. The engineering efforts are conducted at the appropriate level of fidelity and rigor needed to achieve trustworthiness and assurance objectives.

Peter Neumann described the concept of trustworthiness in [2] as follows:

“By trustworthiness, we mean simply worthy of being trusted to fulfill whatever critical requirements may be needed for a particular component, subsystem, system, network, application, mission, enterprise, or other entity. Trustworthiness requirements might typically involve (for example) attributes of security, reliability, performance, and survivability under a wide range of potential adversities. Measures of trustworthiness are meaningful only to the extent that (a) the requirements are sufficiently complete and well defined, and (b) can be accurately evaluated.”

Systems security engineering provides complementary engineering capabilities that extend the concept of trustworthiness to deliver trustworthy secure systems. Trustworthiness is not only about demonstrably meeting a set of requirements. The requirements must also be complete, consistent, and correct. From a security perspective, a trustworthy system meets a set of well-defined requirements, including security requirements. Through evidence and expert judgment, trustworthy secure systems can limit and prevent the effects of modern adversities. Such adversities come in malicious and non-malicious forms and can emanate from a variety of sources, including physical and electronic. Adversities can include attacks from determined and capable adversaries, human errors of omission and commission, accidents and incidents, component faults and failures, abuses and misuses, and natural and human-made disasters.

“Security is embedded in systems. Rather than two engineering groups designing two systems, one intended to protect the other, systems engineering specifies and designs a single system with security embedded in the system and its components.”

-- An Objective of Security in the Future of Systems Engineering [7]

This publication is intended to:

The considerations set forth in this publication are applicable to all federal systems other than those systems designated as national security systems as defined in 44 U.S.C., Section 3542.6 These considerations have been broadly developed from a technical and technical management perspective to complement similar considerations for national security systems and may be used for such systems with the approval of federal officials who exercise policy authority over such systems. State, local, and tribal governments, as well as private sector entities, are encouraged to consider using the material in this publication, as appropriate.

The applicability statement is not meant to limit the technical and management application of these considerations. That is, the security design principles, concepts, and techniques described in this publication are part of a trustworthy secure design approach as described in Appendix D and can be applied in any of the following cases:

The engineering effort includes such activities as concept exploration, preliminary or applied research to refine the concepts and/or feasibility of technologies employed in a new system, and an assessment of alternative solutions. This effort is initiated during the concept and development stages of the system life cycle.

The engineering effort involves migrating or adapting a system or system implementation from one operational environment or set of operating conditions to another operational environment or set of operating conditions.⁷

The engineering effort removes system functions, services, elements, or the entire system from operation and may include the transition of system functions and services to another system. The effort occurs during the retirement stage of the system life cycle and may be conducted while sustaining day-to-day operations.

The engineering effort occurs across a set of constituent systems, each with its own stakeholders, primary purpose, and planned evolution. The composition of the constituent systems into a system of systems as noted in [9] produces a capability that would otherwise be difficult or impractical to achieve. This effort can occur across a variety of system of systems from a relatively informal, unplanned system of systems concept and evolution that emerges over time via voluntary participation to a more formal execution with the most formal being a system of systems concept that is directed, structured, planned, and achieved via a centrally managed engineering effort. Any resulting emergent behavior often introduces opportunities and additional challenges for systems security engineering.

This publication is intended for systems engineers, security engineers, and other engineering professionals. The term systems security engineer is used to include systems engineers and security professionals who apply the concepts and principles and perform the activities and tasks described in this publication.⁸ This publication can also be used by professionals who perform other system life cycle activities or tasks, including:

This publication is intended to serve as a reference and educational resource for systems engineers, engineering specialties, architects, designers, and any individuals involved in the development of trustworthy secure systems and system components. It is meant to be flexible in its application to meet the diverse needs of organizations. There is no expectation that all of the technical content in this publication will be used as part of a systems engineering effort. Rather, the concepts and principles for trustworthy secure design in Appendices D through F as well as the systems life cycle processes and security-relevant activities and tasks in Appendices G through K can be selectively employed by organizations – relying on the experience and expertise of the engineering teams to determine what is correct for their purposes. Applying the content of this publication enables the achievement of security outcomes that are consistent with the systems engineering perspective on system life cycle processes.

The system life cycle processes described in this publication can take advantage of any system or software development methodology. The processes are equally applicable to waterfall, spiral, DevOps, agile, and other approaches. The processes can be applied recursively, iteratively, concurrently, sequentially, or in parallel and to any system regardless of its size, complexity, purpose, scope, operational environment, or special nature. The full extent of the application of the content in this publication is guided by stakeholder capability needs, protection needs, and concerns with particular attention paid to considerations of cost, schedule, and performance.

The remainder of this publication is organized as follows:

The following sections provide additional information to support the engineering of trustworthy secure systems:

The effectiveness of any engineering discipline first requires a thorough understanding of the problem and consideration of all feasible solutions before acting to solve the identified problem. To maximize the effectiveness of systems security engineering, the security requirements for the protection against asset loss must be driven by business, mission, and all other stakeholder asset loss concerns. The security requirements are defined and managed as a well-defined set of engineering requirements and cannot be addressed independently or after the fact.

In the context of systems security engineering, the term protection has a broad scope and is primarily focused on the concept of assets and asset loss resulting in unacceptable consequences. The protection capability provided by a system goes beyond prevention and aims to control the events, conditions, and consequences that constitute asset loss. It is achieved in the form of the specific capability and constraints on system architecture, design, function, implementation, construction, selection of technology, methods, and tools and must be “engineered in” as part of the system life cycle process.

Understanding stakeholder asset protection needs (including assets that they own and assets that they do not own but must protect) and expressing those needs through a set of well-defined security requirements is an investment in the organization’s mission and business success in the modern age of global commerce, powerful computing systems, and network connectivity.

This chapter presents system, systems engineering, trust, and trustworthiness concepts that provide the foundation for engineering trustworthy secure systems.

Many system concepts are important to inform engineering trustworthy secure systems. This includes what constitutes a system, the structure of a system, categories of systems, and the concept of a system of systems.

A system⁹ is an arrangement of parts or elements that together exhibit a behavior or meaning that the individual constituents do not. The properties of a system (i.e., attributes, qualities, or characteristics) emerge from the system’s parts or elements and their individual properties, as well as the relationships and interactions between and among the parts or elements, the system, and its environment [3]. An engineered system is designed or adapted to interact with an anticipated operational environment to achieve one or more intended purposes while complying with applicable constraints [3]. Figure 1 shows the basic structure of a system, including its constituent system elements.¹⁰ 11

Fig. 1. Basic System and System Element Relationship

The purpose of a system is to deliver one or more capabilities. The capabilities may directly or indirectly interact with, control, or monitor physical, mechanical, hydraulic, or pneumatic devices or other systems or capabilities, or it may provide the ability to create, access, manipulate, transmit, store, or share resources, such as data and information.

Figure 2 is a general hierarchical model for the representation of a system. Not all systems, such as networks, are hierarchical in nature. Non-hierarchical systems have models that can more accurately reflect the relationships of their constituent elements. A system element may itself be considered a system (i.e., comprised of other system elements). Realizing a system of interest involves recursively resolving its structure to the point where understandable and manageable system elements can be implemented (i.e., developed, bought, or reused) and subsequently integrating those elements into the system.

Fig. 2. Model for a System and its Elements

A system of systems is a system whose interacting system elements are themselves systems. It provides a unique capability that the constituent systems cannot provide on their own. A system of systems may include inter-system infrastructure, facilities, and processes necessary to enable the constituent systems to integrate or interoperate [10].

Interfacing systems are systems that interact with the system of interest. Interfacing systems have an interface for exchanging data, energy, or other resources with the system of interest. An interfacing system exchanges resources with the system of interest during one or more system life cycle stages, such as a system that interfaces for maintenance purposes or a system used to develop the system of interest. The relationships with interfacing systems can be either bi-directional or one way. Interfacing systems have two specific subsets: enabling systems and interoperating systems.

Figure 3 illustrates the relationship between the system of interest and its interfacing systems in both operational and non-operational (external) environments.

Fig. 3. System of Interest and Interfacing Systems

Systems engineering is a transdisciplinary¹² and integrative approach to enabling the successful realization, use, and retirement of engineered systems. It employs systems principles and concepts, as well as scientific, technological, and management methods to achieve such systems [12]. Systems engineering is system-holistic in nature, whereby the contributions across multiple engineering and specialty disciplines are evaluated and balanced to produce a coherent system capability. Systems engineering applies systems science and systems thinking¹³ to satisfy the often-conflicting needs and priorities of stakeholders within the constraints of cost, schedule, performance, and effectiveness. The objective is to limit uncertainty and thereby manage risk. Systems engineering is outcome-oriented and leverages engineering processes to realize a system while effectively managing complexity and serving as the principal integrating mechanism for the technical, management, and support activities related to the engineering effort. Finally, systems engineering is data- and analytics-driven to ensure that all decisions and trades are guided and informed by data produced by analyses conducted with an appropriate level of fidelity and rigor.

Systems engineering efforts are complex, system-specific, and context-dependent,¹⁴ requiring close coordination between the engineering team and stakeholders throughout the system life cycle stages.¹⁵ While systems engineering is typically considered in terms of its developmental role as part of capability acquisition, systems engineering efforts and responsibilities do not end once a system completes development and is transitioned to the operational environment for day-to-day use. Stakeholders responsible for the system’s utilization, support, and retirement provide data to the systems engineering team on an ongoing basis. This data captures the experiences, problems, and issues associated with the operation, maintenance, and sustainment of the system. Stakeholders also advise the engineering team on system enhancements and improvements made or desired. In addition, field engineering provides on-site, full-system life cycle engineering support for operations, maintenance, and sustainment organizations.

There are many additional resources available that provide more in-depth examinations of systems engineering.¹⁶ Such discussions are beyond the scope of this publication.

The concepts of trust and trustworthiness are foundational to engineering trustworthy secure systems, to the decisions made to grant trust, and to the extent that trust is granted based on demonstrated trustworthiness. Trust is a belief that an entity meets certain expectations and can be relied upon. The terms belief and can imply that trust may be granted to an entity whether the entity is trustworthy or not. A trustworthy entity is one for which sufficient evidence exists to support its claimed trustworthiness. Thus, trustworthiness is the demonstrated ability and, therefore, the worthiness of an entity to be trusted to satisfy expectations, including satisfying expectations in the face of adversity. Since trustworthiness is something demonstrated, it is based on evidence that supports a claim or judgment of an entity being worthy of trust [2] [20] [21].

Since trust is not necessarily based on a judgment of trustworthiness, the decision to trust an entity should consider the significance (i.e., consequences, effects, and impacts) of expectations not being fulfilled because of non-performance – whether due to incompetence, deficiency, or failure. Trust that is granted without establishing the required trustworthiness is a significant contributor to risk. The concepts of trust and trustworthiness are discussed in Appendix F.

In January 2022, INCOSE released the Systems Engineering Vision 2035 [16]. It is intended to inspire, guide, and inform the strategic direction for the global systems engineering community. A core element identified for the future state of systems engineering is increased confidence in systems to improve the practice of engineering trusted systems.

As noted in [7], a key problem to address in realizing Vision 2035 is that “systems security has moved from its traditional focus on trust to a more singular focus on risk.” The need is to prove a level of system security through evidence-based assurance.

This chapter describes the aspects necessary for a systems engineering perspective on security. A systems engineering perspective on security requires an understanding of the concept of security (Section 3.1), the concept of an adequately secure system (Section 3.2), and the characteristics of systems (Section 3.3). It also requires an understanding of the concept of assets (Section 3.4), the concepts of loss and loss control (Section 3.5), how to reason about asset loss (Section 3.6), and how to determine protection needs (Section 3.7). In satisfying such needs, specific viewpoints (Section 3.8) and how security is demonstrated are considered, including what is adequate (Section 3.9). The systems engineering subdiscipline that encompasses these considerations is referred to as systems security engineering (Section 3.10).

A system with freedom from those conditions that can cause a loss of assets with unacceptable consequences must provide the intended behaviors and outcomes and also avoid any unintended behaviors and outcomes that constitute a loss. The term intended is reflected in two cases, both of which must be satisfied:

A system that delivers a capability per the design intent but inconsistent with the user intent constitutes a loss. For example, vehicle control loss might result from a failure in the vehicle’s steering control function (i.e., failure to meet the design intent) or through an attack that takes control away from the driver (i.e., failure to meet the user intent).

The primary security objective is to ensure that only the intended behaviors and outcomes occur, both with the system and within the system.¹⁷ Every security need and concern derive from this objective, which is based on the concept of authorization for what is and is not allowed.¹⁸ As such, the primary security control objective is enforcing constraints in the form of rules for allowed and disallowed behaviors and outcomes. This control objective – and a foundational principle of trustworthy secure design – is Mediated Access. If access is not mediated (i.e., controlled though enforcing constraints) following a set of non-conflicting rules, then no basis exists upon which to claim that security is achieved.

The rules for mediated access are stated in a set of security policies¹⁹ that reflect or are derived from laws, directives, regulations, life cycle concepts,²⁰ requirements, or other specifically stated stakeholder objectives. A security policy includes a scope of control that establishes bounds within which the policy applies. Security policy rules are stated in terms of subjects (active entities), objects (passive entities), and the operations that the subject can perform or invoke on the object.²¹ The rules govern subject-to-object and subject-to-subject behaviors and outcomes. Each security policy rule must be accurate, consistent, compatible, and complete with respect to stakeholder objectives for the defined scope of control.²² Inconsistency, incompatibility, inaccuracy, or incompleteness in the security policy rules lead to protection gaps. It is equally important that the security protection capabilities of the system are aligned with and can achieve the expectations of the policy.

Privileges²³ define the set of allowed and disallowed behavior and outcomes granted to a subject. Privileges are the basis for making mediated access decisions. A restrictive default practice for security policy enforcement is to design the enforcement mechanism to allow only what the policy explicitly allows and to deny everything else. For a system to be deemed trustworthy secure, there must be sufficient confidence that the system is capable of enforcing the security policy on a continuous basis for the duration of the time that the policy is in effect (Appendix F).

Adequate security is a concept that enables meaningful judgments about the idealistic nature of security objectives. The definition of security expresses an ideal that encapsulates three essential characteristics of a secure system:

These characteristics are to be achieved to the extent practicable, resulting in a gap between the ideal secure system and the security performance that the system can dependably achieve.²⁴ The judgment that a system is adequately secure²⁵ requires an evidence-based determination that security performance is optimized against all other performance objectives and constraints. The scope of conditions relevant to security and the acceptable level of security are specific to stakeholder needs. To be adequately secure, the system:

As secure as reasonably practicable means that an incremental improvement in security would require a disproportionate deterioration of meeting other system cost, schedule, or performance objectives; would violate system constraints; or would require unacceptable concessions such as an unacceptable change in the way operations are performed.

An adequately secure system does not necessarily preclude all of the conditions that can lead to or result in undesirable consequences. The minimum tolerable levels of security performance and interpretations of as secure as reasonably practicable may not be fixed for the life of a system. The information gathered while the system is in use and the lessons learned may guide and inform modifications that raise the bar on either or both (tolerability and practicability).

The concept of adequately secure is, therefore, inherently context-dependent, and subjective in nature. It is based on assertions and expectations about the system security objectives and determining how well those objectives have been achieved. Figure 4 illustrates the trade-offs between system security and the cost, schedule, and technical performance of the system.

Fig. 4. System Security and Cost/Schedule/Technical Performance

Judging the adequacy of system security requires an understanding of system states. All systems operate in and transition between a set of states. These states and transitions may correspond to or be defined by characteristics of the system, such as how the system functions (e.g., start, run, idle, recovery), how the system is used (e.g., operational, training, maintenance, peacetime, wartime), and by environmental conditions (e.g., under fire or not, temperature ranges). There are security characteristics that determine whether each state or transition is secure, insecure, or indeterminate (i.e., unknown whether secure or insecure). Adequate security depends on being able to distinguish among secure, insecure, and indeterminate states and to keep the system operating in secure states by applying the principles of Protective Failure and Protective Recovery.

System states may be secure states (i.e., what states are desired and allowed) and insecure states (i.e., what states are not desired nor allowed). Ideally, a secure system is a system that begins execution in a secure state and does not transition to an insecure state. That is, every state transition results in the same or another secure state. Each state transition must also be secure. Figure 5 illustrates a subset of these idealized secure system state transitions.

Fig. 5. Idealized Notional Secure System State Transitions

Protective failure requires the ability to (1) detect that the system is in an insecure state and (2) detect a transition that will place the system into an insecure state for the purposes of responding to avoid the propagation of new failure. Protective failure calls for responsive and corrective actions, including (when needed) transitioning to a secure halt state with a protected recovery to allow for the continuation of operations in a reconstituted, reconfigured, or alternative secure operational mode. Other stakeholder objectives may necessitate the continuation of operations in a less-than-fully-secure state and should be reflected as necessary in such things as policy and requirements (Section C.3).

Protective recovery requires the ability to take reactive, responsive, or corrective action to securely transition from an insecure state to a secure state (or a less insecure state). The secure state achieved after completing protective recovery actions includes those actions that limit or prevent any further state transition and those that constitute a type of degraded capability, mode, or operation.

The characteristics of systems, their interrelationships with other systems, and their roles within a system of systems all impact security and determinations of adequate security and system trustworthiness. These system characteristics can include:

An asset is an item of value. There are many different types of assets. Assets are broadly categorized as either tangible or intangible. Tangible assets include physical items, such as hardware, computing platforms, other technology components, and humans. Intangible assets include humans, firmware, software, capabilities, functions, services, trademarks, intellectual property, data, copyrights, patents, image, or reputation.²⁸ Within asset categories, assets can be further identified and described in terms of common asset classes as illustrated in Table 1.

Table 1. Common Asset Classes

Assets may also be considered as individual items or as an aggregate or group of items that spans asset types or asset classes (e.g., personnel data, fire control function, environmental sensor capability). This publication uses the term asset of interest to emphasize and establish bounds on the scope of reasoning for a specific asset, asset type, or asset class. The valuation of an asset is a key input in decision-making about investments to protect an asset (Section 3.6). For those cases where an asset is associated with multiple stakeholders, there may be differing, contradictory, competing, or conflicting views about the valuation that must be resolved.

Loss is the experience of having an asset taken away or destroyed or the failure to keep or to continue to have an asset in a desired state or form.³² A loss typically results from an adverse event or condition that causes unacceptable ramifications, consequences, or impacts. A specific loss is determined and assessed independent of the causal events and conditions necessary to produce the loss (i.e., the triggering event, such as an error of omission, or the exploitation event, such as an attack). Examples of resultant adverse events or conditions and their ramifications, impacts, or consequences include:

While the loss condition or event is negative relative to the intended norm, the effect of the loss can be either neutral/inconsequential or negative/consequential. For example, a flat tire on a vehicle that is used only for off-road excursion is neutral/inconsequential if no such excursion is planned or affected.

Loss may occur because of a single or combination of intentional or unintentional causes, events, and conditions. These may include the authorized or unauthorized use of the system; intentional acts of disruption or subversion; human and machine faults, errors, and failures; human acts of misuse and abuse; and the by-product of emergence, side effects, and feature interaction. These losses may be inconsequential to the mission or business objectives that the system supports. The objectives may still be achieved despite suffering an immediate or eventual loss that impacts other stakeholder objectives.

The potential to experience loss suggests the need for loss control objectives that serve as the basis for judgments about effectively addressing the prevention and limiting of loss. This includes the resultant adverse events and conditions and their ramifications. The loss control objectives also serve as the basis to acquire evidence of assurance that the system as designed, built, used, and sustained will adequately protect against loss while achieving its design intent. The loss control objectives reflect an ideal to preserve the assets’ characteristics (i.e., state, condition, form, utility) to the extent practicable despite the potential for those characteristics to be changed. The objectives accept uncertainty in the form of limits to what can be done (i.e., not all losses can be avoided) and limits to the effectiveness of what is done (i.e., anything done has its scope of effectiveness and set of potential failure modes).

Due to uncertainty, it is not possible to guarantee that some form of loss will not occur. There is a need to emphasize protection against the effects of loss, including cascading or ripple events (i.e., the immediate effect of a loss causes some additional unintended or undesired effects or causes additional losses to occur). Thus, holistically protecting against loss and the unintended or undesired effects of loss considers the full spectrum of possible loss across types of losses and loss effects associated with each asset class. This is important considering that all forms of adversity are not knowable. Therefore, it is prudent to ensure that there is focus on the effect to be controlled rather than on the cause when protecting against loss.

The loss control objectives in Table 2 address the possibilities to control the potential for loss and the effects of loss given the limits of certainty, feasibility, and practicality. Collectively, the loss control objectives include the concerns attributed to security and to system survivability, safety, and resilience. Note that satisfying loss control objectives may require trade-offs. Avoiding or limiting the loss of one asset may come at the expense of not avoiding or limiting the loss of another asset, as well as having trade-offs with other objectives (e.g., cost and schedule).

Table 2. Loss Control Objectives

As shown in Figure 6, the elements of a structured approach to reason about asset loss include the (1) context of loss, (2) confidence in addressing loss, (3) significance of loss, (4) addressing loss, and (5) cause of loss. The elements provide an asset-protection basis to determine the objectives for a secure system, optimize the system protection capability, and judge the overall suitability and effectiveness of the implemented protections.³³ The elements are also grouped into two objectives to facilitate reasoning about the asset of interest:

Fig. 6. Reasoning about Asset Protection

The asset of interest is the asset class, asset type, or individual asset being addressed. Reasoning about loss is based on the asset of interest. Distinguishing the asset of interest from all other assets provides clarity in the interpretation of loss for the asset of interest and the associated judgments of the suitability and effectiveness of protections employed. A focus on a specific asset class, type, or discrete element also enables precise traceability to requirements that support the analysis needed to determine the protection-relevant impact of changes to requirements.

The context of loss establishes the boundary, scope, and time frame for the reasoning, analyses, assessments, and conclusions about the asset of interest. The context of loss also provides a basis to relate and trace asset dependencies and interactions and to group assets for protection. The context of loss time frame is particularly important because the asset of interest has a life cycle³⁵ that is different from the system of interest.³⁶ For example, the asset of interest may be created, configured, or modified outside of the scope of control of the system of interest yet be within the scope of the engineering effort. The asset of interest, once within the scope of control of the system of interest, may have differing protection needs associated with the state or mode of the system (e.g., the system operational mode protection may differ from the system training mode). Additionally, system life cycle assets (Section 3.8) may only exist within a development or production system and their associated supporting environments. The effect of the loss for these assets may transfer to a loss associated with the system of interest. Therefore, the context of loss includes the life cycle of the asset, the state and mode of the system, and other time-based periods or characteristics during which loss is addressed.

A financial portfolio (i.e., an asset or collection of assets) with specific investment objectives and risk acceptance considerations may be created by a financial advisor for a client, funded by the client, and subsequently managed using multiple systems across one or more institutional investment firms throughout the portfolio’s life cycle. Each asset of interest within the portfolio may have differing protection needs at different times depending on the type of asset, market conditions, regulatory jurisdiction, risk position, and other asset management factors that are imposed on the system.

The significance of loss is the adverse effect (consequence) on the asset of interest or the resultant adverse effect associated with the asset. The significance of loss is best described as an experience that is to be avoided, thereby warranting an investment to protect against the loss occurring and to minimize the extent of the adverse effect should the loss occur. The significance of loss is determined and assessed as an effects-based judgment. That is, it is determined without any consideration of how or why the loss occurs, the probability or likelihood of the loss occurring, and any intent or the absence of intent related to the loss.³⁷

The significance of loss answers the following questions:

The significance of loss requires clarity in what loss means for the asset of interest. Examples of terms used to describe asset loss include ability, accessibility, accuracy, assurance, advantage (technological, competitive, combatant), capability, control, correctness, existence, investment, ownership, performance, possession, precision, quality, satisfaction, and time.

The significance of loss due to a flat tire is determined and assessed without consideration for how or why the tire became flat (e.g., puncture, manufacturing defect, impact with curb or other object) and without any consideration of malicious intent (e.g., tire cut, valve stem loosened). Regardless of how or why the tire became flat, the significance of loss remains the same (e.g., loss of control if the vehicle is moving, inability to drive if the vehicle is stationary, time lost to replace or repair the tire to make the vehicle operable). The significance of loss due to a flat tire includes the inability to steer the vehicle, and the resultant adverse effect may be to impact some other object (i.e., a crash). The adverse effect of the loss of steering (loss of control) is specific, while the adverse effect of a crash is general (many other circumstances may result in a crash without any loss of the ability to steer the vehicle).

Confidence in addressing loss ensures that protections have a body of objective evidence that demonstrates the effectiveness, sufficiency, and suitability of protective measures to satisfy asset protection needs. Confidence in addressing loss is cumulative. It begins with determining the loss concerns for the asset of interest and continuously builds as those concerns are better understood and addressed across the context of loss, the significance of loss, the causes of loss, and how loss is addressed. The evidence basis that provides confidence is informed by the verification and validation activities that occur throughout the life cycles of the assets and the system, including requirements elicitation and analysis. A key informing element to those activities is to ensure that the results contribute to the confidence sought.

The cause of loss³⁸ is the individual or combination of events, conditions, and circumstances that result in some form of loss of an asset. The causes of asset loss constitute a continuum that includes intentional, unintentional, accidental, incidental, misuse, abuse, error, defect, fault, weakness, and failure events and conditions [26]. This continuum spans all human-based, machine-based, physical-based, and nature-based drivers of loss. The following considerations apply to reasoning about the causes of loss:

Finally, the causes of asset loss answer the following questions:

However, determining how loss can occur does not require asking or answering the question, “What is likely or probable to happen?”³⁹

Addressing loss occurs through the protective measures that enforce constraints to ensure that only authorized and intended behaviors and outcomes of the system occur. These include:

The terminology used to describe means and methods includes mechanisms, configurations, controls, safeguards, countermeasures, features, techniques, overrides, practices, procedures, processes, and inhibits. These may be applied in accordance with governing policies, regulations, laws, practices, standards, and techniques.

Do not focus on what is likely to happen. Instead, focus on what can happen, and be prepared. That is what systems security engineering means by adopting a preemptive and reactive strategy (Section D.2) in the form of a concept of secure function that addresses the spectrum of asset loss and associated consequences. This means proactively planning and designing to prevent the loss of an asset that you are not willing to accept, to be able to minimize the consequences should such a loss occur, and to be in an informed position to reactively recover from the loss when it does happen.

Stakeholders need to achieve their mission or business objectives in a secure manner that preserves assets and limits the extent of asset loss. Asset protection must be continuous, thereby making it possible for stakeholders to have a realistic expectation of continuous success in the ability of their systems to support and achieve their objectives.

The scope and expectations for the protection of assets is foundational to achieving the design intent for a trustworthy secure system. Protection needs typically correlate to the severity of consequences associated with the loss of an asset. The protection needs are determined from all needs, concerns, priorities, and constraints to protect and preserve stakeholder and system assets. There are three perspectives for protection needs: (1) the stakeholder perspective, (2) the system perspective, and (3) the trades perspective. Figure 7 illustrates the key input sources used to define protection needs and the outputs derived from the specification of those needs.

Fig. 7. Defining Protection Needs

The purpose of establishing the need for protection is to decide what assets to protect and to determine the priority given to such protection. This can be accomplished without considering a cause or condition against which to protect. As shown in Figure 8, the need for protection is derived from the relationship among the asset of interest, context of loss, type of loss, and the consequences of loss. This approach establishes the need for protection that – once validated by stakeholders across all assets of interest – provides the basis for developing security objectives and requirements.⁴⁰

Fig. 8. Relationship among Asset, Loss, and Consequence

To summarize, the following considerations impact the identification of protection needs:

The stakeholder perspective is based on the assets that belong to stakeholders. Therefore, those stakeholders determine the protection needs. The system perspective is based on the assets necessary for the system to function. These assets are determined by system design decisions and the criticality and priority⁴¹ of the asset in providing or supporting the functions of the system. Stakeholders are typically unaware of the existence of system assets and are not able to make decisions about the protection needs for system assets. The protection of system assets is an element of trustworthy secure system design.

Protection needs are continuously reassessed and adjusted as variances, changes, and trades occur throughout the system life cycle. These include the maturation of the system design and life cycle concepts, improved understanding of the operational environment (e.g., a more thorough understanding of adversities), and changes in understanding of the consequences of asset loss. Revisiting protection needs is a necessary part of the iterative nature of systems engineering. Systems security engineering is necessary to ensure completeness in understanding the problem space, exploring all feasible solutions, and engineering a trustworthy secure system.

Three predominant viewpoints of system security include system function, security function, and life cycle assets. These viewpoints shape the considerations that are used as trustworthy secure design considerations for any system type, intended use, and consequence of system failure.

Every system is delivered to satisfy stakeholder capability needs. These needs constitute the system function – the system’s purpose or role as fulfilled by the totality of the capability it delivers combined with its intended use. The system function is the predominant viewpoint and establishes the context for the security function and the associated system life cycle assets.

The stakeholder capability needs include the protection capability needs. The protection needs parallel the concept of stakeholder capability needs and constitute the system’s security function – the totality of the system’s purpose or role to securely satisfy stakeholder capability needs. The security function enforces security-driven constraints as part of the overall system design. The purpose of the constraints is to avoid, reduce, and tolerate susceptibilities, defects, weaknesses, and flaws in the system that may constitute vulnerabilities that can be exploited or triggered. These vulnerabilities can reside within the system’s structure or behaviors and can have the effect of countering, defeating, or minimizing the ability of the system to effectively satisfy its design intent to deliver the required capability. Thus, the constraints also enable the synthesis of the security function within the system function in a non-conflicting manner.

The security function of the system has both passive and active aspects:

part of the system structure and are, therefore, embodied in the architecture of the system. For example, the functional architecture may segment system functions (including security functions) into different subsystems, reducing the possibility of interference among functions as well as limiting the propagation of erroneous behavior. Passive aspects inherently reduce the susceptibility of the system to exposure, hazard, and vulnerability, thereby limiting if not eliminating the potential for loss scenarios. The employment of passive aspects generally enables greater confidence in the protection capability of the system.

Passive and active aspects of security function factor into trades, as discussed in Section D.4.4. Active aspects may also require additional hardware or loads on existing hardware; increasing demands for size, weight, and power (SWaP); and making active aspects a challenge for SWaP-restricted systems (e.g., satellites).

Life cycle assets are associated with the system but are not engineered into or delivered with the system. Their association with the system means that they can be the direct cause of loss or a conduit/means through which a loss can occur. Life cycle assets have several types:

Demonstrating that a system is adequately secure (Section 3.2) assures stakeholders that their objectives, needs, concerns, and associated constraints have been addressed. Such demonstration must consider the system as an emergent⁴³ whole that consists of:

In particular, the limits of certainty apply to requirements and accepting the potential errors, inconsistencies, or gaps in the completeness and coverage of those requirements. Therefore, the requirements and associated verification and validation methods, while a necessary aspect of demonstrating adequate security, are not sufficient to deem a system as adequately secure. The level of confidence provided must be commensurate with the asset loss consequences addressed. The evidence basis for demonstrating confidence must be recorded, traced, maintained, and evolved as variances that are relevant to demonstrating adequate security occur throughout the system life cycle. Additionally, the evidence basis must be meaningful to subject-matter experts across the subjective, competing, and often contradicting needs and beliefs of stakeholders.

Demonstrating this justified confidence or assurance is achieved by an evidentiary basis provided by systems analyses and other evidence-producing activities.⁴⁵ The evidentiary basis is used within an approach for structured reasoning, as demonstrated in assurance cases (Section 4.3). The reasoning considers the system needs and capabilities, contributing system quantitative and qualitative factors, and how these capabilities and factors produce an evidentiary base upon which further analyses are conducted in the context of system security. In turn, these analyses support substantiated and reasoned conclusions that serve as the basis for consensus among stakeholders that the system is adequately secure (Appendix F).

No system can provide absolute security due to the limits of human certainty, the uncertainty that exists in the life cycle of every system, and the constraints of cost, schedule, performance, feasibility, and practicality. As such, trade-offs made routinely across contradictory, competing, and conflicting needs and constraints are optimized to achieve adequate security, which reflects a decision made by stakeholders.

As a subdiscipline of systems engineering, systems security engineering is a transdisciplinary and integrative approach to enabling the successful realization, use, and retirement of engineered trustworthy secure systems. Systems security engineering employs systems, security, and other principles and concepts, as well as scientific, technological, and management methods. Systems security engineering ensures that these principles, concepts, methods, and practices are applied during the system life cycle to achieve stakeholder objectives for assured trustworthiness and asset protection despite adversity. It also helps to reduce and control the causes and conditions that can lead to vulnerability and, as a result, reduces the effect that adversity can have on the system.

Systems security engineering overlaps with other subdisciplines and leverages multiple specialties to accomplish systems security engineering activities and tasks. These specialties include computer security; communications security; transmission security; electronic emissions security; anti-tamper protection; physical security; information, software, hardware, and supply chain assurance; and technology specialties, such as biometrics and cryptography.

Systems security engineering also leverages contributions from other enabling engineering disciplines and specialties to analyze and manage complexity, interconnectedness, dynamicity, and susceptibility associated with hardware, software, and firmware-based technologies.⁴⁶ This includes the development, manufacturing, handling, and distribution of technologies throughout the system life cycle.⁴⁷

Figure 9 illustrates the relationships among systems engineering, systems security engineering, and contributing security and other specialty engineering areas.

Fig. 9. Systems Engineering and Other Specialty Engineering Disciplines

As part of a transdisciplinary systems engineering effort to deliver a trustworthy secure system, systems security engineering:

A system is engineered to achieve a capability driven by stakeholder mission and business needs. Security is an emergent property of a system that is achieved through a principled engineering process that reflects the stakeholder’s protection needs and concerns. The engineered security capability contributes to the overall system capability that satisfies stakeholder mission and business needs. No system can provide absolute security due to the limits of human certainty, the uncertainty that exists in the life cycle of every system, and the constraints of cost, schedule, performance, feasibility, and practicality. As such, trade-offs made routinely across contradictory, competing, and conflicting needs and constraints are optimized to provide adequate security.

The systems security engineering framework [29] provides a conceptual view of the key contexts within which systems security engineering activities are conducted. It defines, bounds, and focuses activities and tasks toward achieving stakeholder security objectives and presents a coherent, well-formed, evidence-based case to support judgments about achievement of the objectives.⁵⁰ The framework is independent of system type and engineering or acquisition process model. It is not to be interpreted as a sequence of flows or steps but rather as a set of interacting contexts, each with its own checks and balances. The systems security engineering framework emphasizes an integrated, holistic security perspective across all system life cycle stages and is applied to satisfy the milestone objectives of each life cycle stage.

The framework defines three contexts for conducting activities and tasks: (1) the problem context, (2) the solution context, (3) and the trustworthiness context. The three contexts help to ensure that the engineering is driven by a sufficiently complete understanding of the problem. This understanding drives the effort to provide the solution and is supported by a set of activities to design and realize the solution. It also demonstrates the worthiness of the solution in providing adequate security across competing and often conflicting constraints.

While the framework appears to follow a sequential execution across the three contexts, it is intended to be implemented in a closed loop iterative and recursive manner. This approach facilitates a refinement of the problem statement, the proposed solution, and the trustworthiness objectives as the design evolves from concept to the realized solution. The closed loop feedback facilitates interactions among the three framework contexts and the requisite system security analyses to continuously identify and address variances that are introduced into the engineering effort. The feedback loop also helps to achieve continuous process improvement for the system, including viewing the outputs of one life cycle phase (i.e., the solution to the phase) as the inputs to the next phase (i.e., the problem for the next phase).

The three framework contexts share a common foundational base of system security analyses, including system analyses with security interpretations of the analyses results (Section H.6). System security analyses produce data to support engineering and stakeholder decision-making.⁵¹ Such analyses are differentiated for application within the problem, solution, and trustworthiness contexts and employ a variety of concepts, principles, techniques, means, methods, processes, practices, and tools. System security analyses:

Figure 10 illustrates the systems security engineering framework and its key components.

Fig. 10. Systems Security Engineering Framework

The problem context defines the basis for an adequately secure system. It focuses on stakeholders’ concerns about unacceptable losses given their mission, operational capability, and performance needs and concerns, as well as all associated cost, schedule, performance, and risk-driven constraints. The problem context enables the engineering team to focus on acquiring as complete an understanding of the stakeholder problem as practical, to explore all feasible solution class options, and to select the solution class option or options to be pursued. The problem context includes:

The security objectives are foundational, establishing and scoping what it means to be adequately secure in terms of protection against asset loss and the significance of such loss. The security objectives have associated measures of success. These measures of success constitute specific and measurable criteria relative to operational performance measures and stakeholder concerns. Measures of success include both the strength of protection and the level of assurance in the protection capability that has been engineered. These measures influence developing security requirements and assurance claims.

Protection needs are determined based on the security objectives, life cycle concepts, and stakeholder concerns. The protection needs are subsequently transformed into stakeholder security requirements and associated constraints, as well as the measures needed to validate that all requirements have been met. A well-defined and stakeholder-validated problem definition and context provide the foundation for all systems engineering and systems security engineering and supporting activities.

The problem context may be interpreted within a life cycle phase as being informed by solutions from earlier life cycle stages, thereby providing a more accurate statement of the problem and its associated constraints. For example, the stakeholder requirements may be the solution of an early life cycle phase, which then constrains activities completed in later life cycle stages.

The solution context establishes the security aspects and constraints for the architecture and design of the system that (1) satisfies the requirements and objectives of the problem context, (2) realizes the design for the system, and (3) produces sufficient evidence to demonstrate that the requirements and objectives of the problem context have been satisfied.⁵³ The solution context is based on a balanced preemptive and reactive system security protection strategy⁵⁴ that exercises control over events, conditions, asset loss, and the significance of loss to the degree possible, practicable, and acceptable to stakeholders. The solution context includes:

The security aspects of the solution include the development of a system protection strategy; allocated, decomposed, and derived security requirements; security architecture views and viewpoints; security design; security aspects, capabilities, and limitations in the system life cycle procedures; and security performance verification measures. The security aspects of the solution are realized during the implementation of the system design in accordance with the system architecture and in satisfaction of the security requirements. The evidence associated with the security aspects of the solution is obtained with a fidelity and rigor influenced by the level of assurance⁵⁵ targeted by the security objectives. Assurance evidence is obtained from standard systems engineering verification methods (e.g., analysis, demonstration, inspection, testing, and evaluation) and complementary validation methods applied against the stakeholder requirements. Application of the solution context may be interpreted to provide a part of the solution, constraining the next iteration of the problem context.

The trustworthiness context is a decision-making context that provides an evidence-based demonstration – through reasoning – that the system of interest is deemed trustworthy (or not) based on a set of claims derived from security objectives. This context consists of:

The trustworthiness context is grounded in the concept of an assurance case. An assurance case is a well-defined and structured set of arguments and a body of evidence showing that a system satisfies specific claims.⁵⁶ Assurance cases provide reasoned, auditable artifacts that support the contention that a top-level claim or set of claims is satisfied, including systematic argumentation and underlying evidence and explicit assumptions that support the claims [30]. The claims may build from subclaims. For a given system life cycle stage, an outcome may sufficiently satisfy a subclaim or set of subclaims, such as a subclaim that stakeholder requirements are sufficiently comprehensive to support a claim that the realized system is adequately secure.

Assurance cases are used to demonstrate that a system exhibits some complex emergent property, such as safety, security, resilience, reliability, or survivability. An effective security assurance case contains foundational security claims derived from security objectives, credible and relevant evidence that substantiates the claims, and valid arguments that relate the various evidence to the supported security claims. The result provides a compelling statement that adequate security has been achieved and driven by stakeholder needs and expectations.

Assurance cases typically include supporting information, such as assumptions, constraints, and inferences that affect the reasoning process. As part of assurance case development, subject-matter expert analyses determine that all security claims are substantiated by the evidence and the arguments relating the evidence to the claims. Assurance cases must be maintained in response to variances throughout the engineering effort.

The specific form of an assurance case and the level of rigor and formality in acquiring the evidence required is a trade space consideration. It involves the target (i.e., desired) level of assurance, the nature of the consequences for which assurance is sought, and the size and complexity of the dimensions that factor into determining trustworthiness. The assurance case is an engineering construct and must be managed to ensure that the expended effort is justified by the need for the evidence in determining trustworthiness. The assurance claims are the key trustworthiness factor and are developed from the security objectives and associated measures of success independent of the system realization and its supporting evidence. Trustworthiness and assurance are discussed further in Appendix F.

Establishing the problem, solution, and trustworthiness contexts as key components of a systems security engineering framework helps ensure that the security of a system is based on achieving a sufficiently complete understanding of the problem as defined by a set of stakeholder security objectives, security concerns, protection needs, and security requirements. This understanding is essential to developing effective security solutions – that is, a system that is sufficiently trustworthy and adequately secure to protect stakeholder’s assets in terms of loss and the associated consequences.

[99] International Organization for Standardization/International Electrotechnical Commission (2021) ISO/IEC 15026-4:2021 – Systems and software engineering – Systems and software assurance – Part 4: Assurance in the life cycle. https://www.iso.org/standard/74396.html

[100] International Organization for Standardization/International Electrotechnical Commission (2008) ISO/IEC 21827:2008 – Information technology – Security techniques – Systems Security Engineering – Capability Maturity Model® (SSE-CMM®). https://www.iso.org/standard/44716.html

[101] International Organization for Standardization/Technical Specification (2010) ISO/TS 18152:2010 – Ergonomics of human-system interaction – Specification for the process assessment of human-system issues. https://www.iso.org/standard/56174.html

[102] International Organization for Standardization/International Electrotechnical Commission (2010) ISO/IEC TR 25060:2010 – Systems and software engineering – Systems and software product Quality Requirements and Evaluation (SQuaRE) – Common Industry Format (CIF) for usability: General framework for usability-related information. https://www.iso.org/standard/35786.html

[103] International Organization for Standardization/International Electrotechnical Commission (2014) ISO/IEC 25063:2014 – Systems and software engineering – Systems and software product Quality Requirements and Evaluation (SQuaRE) – Common Industry Format (CIF) for usability: Context of use description. https://www.iso.org/standard/35789.html

[104] International Organization for Standardization (2010) ISO 9241-210:2010 – Ergonomics of human-system interaction – Part 210: Human-centered design for interactive systems. https://www.iso.org/standard/52075.html

[105] International Organization for Standardization/International Electrotechnical Commission (2019) ISO/IEC 25030:2019 – Software Engineering – Software product Quality Requirements and Evaluation (SQuaRE) – Quality Requirements. https://www.iso.org/standard/72116.html

[106] International Organization for Standardization/International Electrotechnical Commission (2009) ISO/IEC 15408-1:2009 – Information technology – Security techniques – Evaluation criteria for IT security – Part 1: Introduction and general model. https://www.iso.org/standard/72891.html

[107] International Organization for Standardization/International Electrotechnical Commission (2008) ISO/IEC 15408-2:2008 – Information technology – Security techniques – Evaluation criteria for IT security – Part 2: Security functional requirements. https://www.iso.org/standard/72892.html

[108] International Organization for Standardization/International Electrotechnical Commission (2008) ISO/IEC 15408-3:2008 – Information technology – Security techniques – Evaluation criteria for IT security – Part 3: Security assurance requirements. https://www.iso.org/standard/46413.html

[109] International Organization for Standardization/International Electrotechnical Commission (2011) ISO/IEC 27034-1:2011 – Information technology – Security techniques – Application security – Part 1: Overview and concepts. https://www.iso.org/standard/44378.html

[110] International Council on Systems Engineering (2010) Systems Engineering Measurement Primer – INCOSE TP-2010-005-02. https://www.incose.org/docs/default-source/ProductsPublications/systems-engineering-measurement-primer---december-2010.pdf

[111] International Organization for Standardization/International Electrotechnical Commission (2021) ISO/IEC 27036-1:2021 – Cybersecurity – Supplier relationships – Part 1: Overview and concepts. https://www.iso.org/standard/82905.html

[112] International Organization for Standardization/International Electrotechnical Commission (2022) ISO/IEC 27036-2:2022 – Cybersecurity – Supplier relationships – Part 2: Requirements. https://www.iso.org/standard/82060.html

[113] International Organization for Standardization/International Electrotechnical Commission (2013) ISO/IEC 27036-3:2013 – Information technology – Security techniques – Information security for supplier relationships – Part 3: Guidelines for information and communication technology supply chain security. https://www.iso.org/standard/59688.html

[114] International Organization for Standardization/International Electrotechnical Commission (2015) ISO/IEC 16350:2015 – Information technology – Systems and software engineering – Application management. https://www.iso.org/standard/57922.html

[115] International Organization for Standardization/International Electrotechnical Commission (2006) ISO/IEC 14764:2006 – Software Engineering – Software Life Cycle Processes – Maintenance. https://www.iso.org/standard/39064.html

[116] International Organization for Standardization (2018) ISO 10004:2018 – Quality management – Customer satisfaction – Guidelines for monitoring and managing. https://www.iso.org/standard/71582.html

[117] International Organization for Standardization/International Electrotechnical Commission/Institute of Electrical and Electronics Engineers (2019) ISO/IEC/IEEE 42020:2019 – Software, systems and enterprise – Architecture processes. https://www.iso.org/standard/68982.html

[118] Institute of Electrical and Electronics Engineers (2018) Std. P1012, IEEE Standard for System, Software, and Hardware Verification and Validation, IEEE Computer Society. https://standards.ieee.org/ieee/1012/7324

[119] International Organization for Standardization/International Electrotechnical Commission (2013) ISO/IEC 29119-1:2013 – Software Testing: Concepts and Definitions. https://www.iso.org/standard/45142.html

[120] International Organization for Standardization/International Electrotechnical Commission (2021) ISO/IEC 29119-2:2021 – Software and systems engineering – Software testing – Part 2: Test processes. https://www.iso.org/standard/79428.html

[121] International Organization for Standardization/International Electrotechnical Commission (2021) ISO/IEC 29119-3:2021 – Software and systems engineering – Software testing – Part 3: Test documentation. https://www.iso.org/standard/79429.html

[122] International Organization for Standardization/International Electrotechnical Commission (2021) ISO/IEC 29119-4:2021 – Software and systems engineering – Software testing – Part 4: Test techniques. https://www.iso.org/standard/60245.html

[123] Roedler G, Jones C (2005) Technical Measurement, International Council on Systems Engineering, INCOSE TP-2003-020-01. https://www.incose.org/docs/default-source/ProductsPublications/technical-measurement-guide---dec-2005.pdf?sfvrsn=4&sfvrsn=4

[124] International Organization for Standardization/International Electrotechnical Commission (2021) ISO/IEC 16085:2021 – Systems and software engineering – Life cycle processes – Risk management. https://www.iso.org/standard/74371.html

[125] International Organization for Standardization (2018) ISO 31000:2018 – Risk management – Guidelines. https://www.iso.org/standard/65694.html

[126] International Organization for Standardization (2017) ISO 10007:2017 – Quality management systems – Guidelines for configuration management. https://www.iso.org/standard/70400.html

[127] Electronic Industries Alliance (2019) EIA 649C, Configuration Management Standard. https://www.sae.org/standards/content/eia649c

[128] International Organization for Standardization/International Electrotechnical Commission/Institute of Electrical and Electronics Engineers (2019) ISO/IEC/IEEE 15289:2019 – Systems and software engineering – Content of life-cycle information items (documentation). https://www.iso.org/standard/74909.html

[129] International Organization for Standardization/International Electrotechnical Commission/Institute of Electrical and Electronics Engineers (2015) ISO/IEC/IEEE 26531:2015 – Systems and software engineering – Content management for product life-cycle, user and service management documentation. https://www.iso.org/standard/43090.html

[130] International Organization for Standardization (2015) ISO 9001:2015 – Quality management systems – Requirements. https://www.iso.org/standard/62085.html

[131] Institute of Electrical and Electronics Engineers (2014) IEEE Std. 730-2014 – IEEE Standard for Software Quality Assurance Processes. https://standards.ieee.org/ieee/730/5284

[132] Department of Defense (2020) DoD Directive 8140.01 – Cyberspace Workforce Management. https://www.esd.whs.mil/Portals/54/Documents/DD/issuances/dodd/814001p.PDF?ver=si7QmZONMCW2tStUt4ws3Q%3D%3D [133] Petersen R, Santos D, Smith MC, Wetzel KA, Witte G (2020) Workforce Framework for Cybersecurity (NICE Framework). (National Institute of Standards and Technology, Gaithersburg, MD), NIST SP 800-181 Revision 1. https://csrc.nist.gov/publications/detail/sp/800-181/rev-1/final [134] International Organization for Standardization/International Electrotechnical Commission (2015) ISO/IEC 33002:2015 – Information technology – Process assessment – Requirements for performing process assessment. https://www.iso.org/standard/54176.html

[133] Petersen R, Santos D, Smith MC, Wetzel KA, Witte G (2020) Workforce Framework for Cybersecurity (NICE Framework). (National Institute of Standards and Technology, Gaithersburg, MD), NIST SP 800-181 Revision 1. https://csrc.nist.gov/publications/detail/sp/800-181/rev-1/final

[134] International Organization for Standardization/International Electrotechnical Commission (2015) ISO/IEC 33002:2015 – Information technology – Process assessment – Requirements for performing process assessment. https://www.iso.org/standard/54176.html

[135] Stember, M (1991) Advancing the social sciences through the interdisciplinary enterprise The Social Science Journal, 28:1, 1-14.

ACM Association for Computing Machinery

AIAA American Institute of Aeronautics and Astronautics

ANSI American National Standards Institute

ASARP As Secure As Reasonably Practicable

CDS Cross-Domain Solutions

CNSS Committee on National Security Systems

COTS Commercial Off-The-Shelf

CUI Controlled Unclassified Information

DoD Department of Defense

EIA Electronic Industries Alliance

EO Executive Order

FISMA Federal Information Security Modernization Act

FOIA Freedom of Information Act

FuSE Future of Systems Engineering

GSN Goal Structuring Notation

IEC International Electrotechnical Commission

IEEE Institute of Electrical and Electronics Engineers

INCOSE International Council on Systems Engineering

ISO International Organization for Standardization

IT Information Technology

ITL Information Technology Laboratory

MOE Measures of Effectiveness

MOP Measures of Performance

NASA National Aeronautics and Space Administration

NICE National Initiative for Cybersecurity Education

NIST National Institute of Standards and Technology

NDIA National Defense Industrial Association

OMB Office of Management and Budget

OT Operational Technology

SEBoK Systems Engineering Body of Knowledge

SecDOP Security Design Order of Precedence

SoS System of Systems

SP Special Publication

SSE Systems Security Engineering

SWaP Size, Weight, and Power

USC United States Code

abstraction — View of an object that focuses on the information relevant to a particular purpose and ignores the remainder of the information. [24]

acquirer — Stakeholder that acquires or procures a product or service from a supplier. [4]

acquisition — Process of obtaining a system, product, or service. [4]

activity — Set of cohesive tasks of a process. [4]

adequate security (systems) — Meets minimum tolerable levels of security as determined by analysis, experience, or a combination of both and is as secure as reasonably practicable (i.e., incremental improvement in security would require an intolerable or disproportionate deterioration of meeting other system objectives, such as those for system performance, or would violate system constraints).

adverse consequence — An undesirable consequence associated with a loss. [61]

adversity — The conditions that can cause a loss of assets (e.g., threats, attacks, vulnerabilities, hazards, disruptions, and exposures).

agreement — Mutual acknowledgement of terms and conditions under which a working relationship is conducted (e.g., memorandum of agreement or contract). [4]

anomaly — Condition that deviates from expectations based on requirements specifications, design documents, user documents, or standards, or from someone’s perceptions or experiences. [24]

anti-tamper — Systems engineering activities intended to prevent or delay exploitation of critical program information in U.S. defense systems in domestic and export configurations to impede countermeasure development, unintended technology transfer, or alteration of a system due to reverse engineering. [70] See tampering.

architecture — Fundamental concepts or properties related to a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution. [71] See security architecture.

architecture (system) — Fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution. [71]

architecture description — A work product used to express an architecture. [71]

architecture framework — Conventions, principles, and practices for the description of architectures established within a specific domain of application and/or community of stakeholders. [71]

architecture view — A work product expressing the architecture of a system from the perspective of specific system concerns. [71]

architecture viewpoint — A work product establishing the conventions for the construction, interpretation, and use of architecture views to frame specific system concerns. [71]

artifact — Work products that are produced and used during a project to capture and convey information (e.g., models, source code). [72]

aspect — The parts, features, and characteristics used to describe, consider, interpret, or assess something.

asset — Anything that has value to a person or organization. [24]

Note 1: Assets have interrelated characteristics that include value, criticality, and the degree to which they are relied upon to achieve organizational mission and business objectives. From these characteristics, appropriate protections are to be engineered into solutions employed by the organization.

Note 2: An asset may be tangible (e.g., physical item such as hardware, software, firmware, computing platform, network device, or other technology components) or intangible (e.g., information, data, trademark, copyright, patent, intellectual property, image, or reputation).

assurance — Grounds for justified confidence that a claim has been or will be achieved. [61]

Note 1: Assurance is typically obtained relative to a set of specific claims. The scope and focus of such claims may vary (e.g., security claims, safety claims), and the claims themselves may be interrelated.

Note 2: Assurance is obtained through techniques and methods that generate credible evidence to substantiate claims.

assurance case — A reasoned, auditable artifact created that supports the contention that its top-level claim (or set of claims) is satisfied, including systematic argumentation and its underlying evidence and explicit assumptions that support the claim(s). [61]

assurance evidence — The information upon which decisions regarding assurance, trustworthiness, and risk of the solution are substantiated.

Note: Assurance evidence is specific to an agreed-upon set of claims. The security perspective focuses on assurance evidence for security-relevant claims, whereas other engineering disciplines may have their own focus (e.g., safety).

availability — Property of being accessible and usable on demand by an authorized entity. [73]

baseline — Formally approved version of a configuration item, regardless of media, formally designated and fixed at a specific time during the configuration item’s life cycle. [74]

Note: The engineering process generates many artifacts that are maintained as a baseline over the course of the engineering effort and after its completion. The configuration control processes of the engineering effort manage baselined artifacts. Examples include stakeholder requirements baseline, system requirements baseline, architecture/design baseline, and configuration baseline.

behavior — The way that an entity functions as an action, reaction, or interaction. How a system element, system, or system of systems acts, reacts, and interacts. [75]

body of evidence — The totality of evidence used to substantiate trust, trustworthiness, and risk relative to the system.

breakdown structure — Framework for efficiently controlling some aspect of the activities for a program or project. [76]

Note: Examples include work breakdown structure, the decomposition of the defined scope of a project into progressively lower levels consisting of elements of work, and product breakdown structure (i.e., decomposition of a product into its components).

claim — A true-false statement about the limitations on the values of an unambiguously defined property called the claim’s property; and limitations on the uncertainty of the property’s values falling within these limitations during the claim’s duration of applicability under stated conditions. [61]

complex system — A system in which there are non-trivial relationships between cause and effect: each effect may be due to multiple causes; each cause may contribute to multiple effects; causes and effects may be related as feedback loops, both positive and negative; and cause-effect chains are cyclic and highly entangled rather than linear and separable. [3]

component — See system element.

concept of operations — Verbal and graphic statement, in broad outline, of an organization’s assumptions or intent in regard to an operation or series of operations of new, modified, or existing organizational systems. [77]

Note 1: The concept of operations is frequently embodied in long-range strategic plans and annual operational plans. In the latter case, the concept of operations in the plan covers a series of connected operations to be conducted simultaneously or in succession to achieve an organizational performance objective.

Note 2: The concept of operations provides the basis for bounding the operating space, system capabilities, interfaces, and operating environment.

concept of secure function — A strategy for the achievement of secure system function that embodies the preemptive and reactive protection capabilities of the system.

Note 1: This strategy strives to prevent, minimize, or detect the events and conditions that can lead to the loss of an asset and the resultant adverse consequences; prevent, minimize, or detect the loss of an asset or adverse asset consequences; continuously deliver system capability at some acceptable level despite the impact of threats or uncertainty; and recover from adverse asset consequences to restore full system capability or recover to some acceptable level of system capability.

Note 2: The concept of secure function is adapted from historical and other secure system concepts, such as the Philosophy of Protection, the Theory of Design and Operation, and the Theory of Compliance.

concern — Matter of interest or importance to a stakeholder. [71]

concern (system) — Interest in a system relevant to one or more of its stakeholders. [71]

configuration item — Item or aggregation of hardware, software, or both that is designated for configuration management and treated as a single entity in the configuration management process. [4]

consequence — Effect (change or non-change), usually associated with an event or condition or with the system and usually allowed, facilitated, caused, prevented, changed, or contributed to by the event, condition, or system. [61]

constraints — Limitation on the system, its design, its implementation, or the process used to develop or modify a system. Limitation that restricts the design solution, implementation, or execution of the system. [31]

Note: A constraint is a factor that is imposed on the solution by force or compulsion and may limit or modify the design.

control — Purposeful action on or within a process to meet specified objectives. The mechanism that achieves the action.

criticality — Degree of impact that a requirement, module, error, fault, failure, or other item has on the development or operation of a system.

customer — Organization or person that receives a product. [78]

cyber-physical system — A system integrating computation with physical processes whose behavior is defined by both the computational (digital and other forms) and the physical parts of the system. [27]

data — Representation of facts, concepts, or instructions in a manner suitable for communication, interpretation, or processing by humans or by automatic means. Collection of values assigned to base measures, derived measures, and/or indicators. [79]

derived requirement — A requirement deduced or inferred from the collection and organization of requirements into a particular system configuration and solution. [31]

Note 1: The next higher-level requirement is referred to as a parent requirement, while the derived requirement from this parent is called a child requirement.

Note 2: A derived requirement is typically identified during the elicitation of stakeholder requirements, requirements analysis, trade studies or validation.

design — Process to define the architecture, system elements, interfaces, and other characteristics of a system or system element. [24] Result of the process to be consistent with the selected architecture, system elements, interfaces, and other characteristics of a system or system element. [4]

Note 1: Information, including the specification of system elements and their relationships, which is sufficiently complete to support a compliant implementation of the architecture.

Note 2: Design provides the detailed implementation-level physical structure, behavior, temporal relationships, and other attributes of system elements.

design characteristics — Design attributes or distinguishing features that pertain to a measurable description of a product or service. [24]

design margin — The margin allocated during design based on assessments of uncertainty and unknowns. This margin is often consumed as the design matures. [17]

domain — A set of elements, data, resources, and functions that share a commonality in combinations of (1) roles supported, (2) rules governing their use, and (3) protection needs. [24]

Note: Security domains may reflect one or any combination of the following: capability, functional, or service distinctions; data flow and control flow associated with capability, functional, or service distinctions; data and information sensitivity; data and information security; or administrative, management, operational, or jurisdictional authority. Security domains that are defined in the context of one or more of these items reflect a protection-focused partitioning of the system that translates to relationships driven by trust concerns.

emergence — The behaviors and outcomes that result from how individual system elements compose to form the system as a whole.

Note: The behavior and outcomes produced by the system are not those of the individual system elements that comprise the system. Rather, the emergent system behavior and outcomes, or properties, result from the composition of multiple system elements.

enabling system — System that supports a system of interest during its life cycle stages but does not necessarily contribute directly to its function during operation. [4]

engineered system — A system designed or adapted to interact with an anticipated operational environment to achieve one or more intended purposes while complying with applicable constraints. [3]

engineering team — The individuals on the systems engineering team with security responsibilities, systems security engineers that are part of the systems engineering team, or a combination thereof.

environment — Context determining the setting and circumstances of all influences upon a system. [71]

error — The difference between desired and actual performance or behavior of a system or system element.

event — Occurrence or change of a particular set of circumstances. [28]

evidence — Grounds for belief or disbelief; data on which to base proof or to establish truth or falsehood.

Note 1: Evidence can be objective or subjective. Evidence is obtained through measurement, the results of analyses, experience, and the observation of behavior over time.

Note 2: The security perspective places focus on credible evidence used to obtain assurance, substantiate trustworthiness, and assess risk.

facility — Physical means or equipment for facilitating the performance of an action (e.g., buildings, instruments, tools). [4]

flaw — Imperfection or defect.

generalized reference monitor concept — An abstract model of the necessary and sufficient properties that must be achieved by any mechanism that enforces a constraint. [36] [37]

incident — Anomalous or unexpected event, set of events, condition, or situation at any time during the life cycle of a project, product, service, or system. [4]

information — Knowledge that is exchangeable amongst users, about things, facts, concepts, and so on, in a universe of discourse. [80]

Note: Although information will necessarily have a representation form to make it communicable, it is the interpretation of this representation (the meaning) that is relevant. The representation form is arguably considered data.

information item — Separately identifiable body of information that is produced, stored, and delivered for human use. [81]

information system — A discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information. [82] See system.

interface — Wherever two or more logical, physical, or both system elements or software system elements meet and act on or communicate with each other. [4]

interoperating system — System that exchanges information with the system of interest and uses the information that has been exchanged. [4]

integrity — Quality of being complete and unaltered. [83]

life cycle — Evolution of a system, product, service, project, or other human-made entity from conception through retirement. [4]

life cycle model — Framework of processes and activities concerned with the life cycle that may be organized into stages, which also acts as a common reference for communication and understanding. [4]

life cycle security concepts — The processes, methods, and procedures associated with the system throughout its life cycle and provide distinct contexts for the interpretation of system security. Life cycle security concepts apply during program management, development, engineering, acquisition, manufacturing, fabrication, production, operations, sustainment, training, and retirement.

likelihood — Chance of something happening. [28]

margin — A spare amount or measure or degree allowed or given for contingencies or special situations. The allowances carried to account for uncertainties and risks. [39] See design margin and operational margin.

mechanism — A process or system that is used to produce a particular result. The fundamental processes involved in or responsible for an action, reaction, or other natural phenomenon. A natural or established process by which something takes place or is brought about.

Note 1: Generally, a means to an end.

Note 2: A mechanism can be technology- or non-technology-based (e.g., apparatus, device, instrument, procedure, process, system, operation, method, technique, means, or medium).

See security mechanism.

module — Program unit that is discrete and identifiable with respect to compiling, combining with other units, and loading. Discrete and identifiable element with a well-defined interface and well-defined purpose or role whose effect is described as relations among inputs, outputs, and retained state. [24]

monitoring — Continual checking, supervising, critically observing or determining the status in order to identify change from the performance level required or expected. [28]

operational concept — Verbal and graphic statement of an organization’s assumptions or intent in regard to an operation or series of operations of a specific system or a related set of specific new, existing, or modified systems. [77]

Note: The operational concept is designed to give an overall picture of the operations using one or more specific systems or set of related systems in the organization’s operational environment from the perspectives of users and operators.

See concept of operations.

operational environment — Context determining the setting and circumstance of all influences on a delivered system.

Note: Operational environments include physical (e.g., land, air, maritime, space) and cyberspace contexts.

operational margin — The margin that is designed explicitly to provide space between the worst normal operating condition and the point at which failure occurs (derives from physical design margin). [3] [6]

operator — Individual or organization that performs the operations of a system. [4]

Note 1: The role of operator and the role of user can be vested, simultaneously or sequentially, in the same individual or organization.

Note 2: An individual operator combined with knowledge, skills, and procedures can be considered an element of the system.

Note 3: An operator may perform operations on a system that is operated or of a system that is operated, depending on whether or not operating instructions are placed within the system boundary.

organization — Group of people and facilities with an arrangement of responsibilities, authorities, and relationships. [4] [78]

Note: An identified part of an organization (even as small as a single individual) or an identified group of organizations can be regarded as an organization if it has responsibilities, authorities, and relationships. A body of persons organized for some specific purpose – such as a club, union, corporation, or society – is an organization.

outcome Result of the performance (or non-performance) of a function or process(es). [84]

party Organization entering into an agreement. [4]

penetration testing Testing used in vulnerability analysis for vulnerability assessment, trying to reveal vulnerabilities of the system based on the information about the system gathered during the relevant evaluation activities. [85]

problem Difficulty, uncertainty, or otherwise realized and undesirable event, set of events, condition, or situation that requires investigation and corrective action. [4]

process Set of interrelated or interacting activities that use inputs to deliver an intended result. [78]

process purpose High-level objective of performing the process and the likely outcomes of effective implementation of the process. [4]

process outcome Observable result of the successful achievement of the process purpose. [86]

product Result of a process. [78]

project Endeavor with defined start and finish criteria undertaken to create a product or service in accordance with specified resources and requirements. [4]

protection needs Informal statement or expression of the stakeholder security requirements focused on protecting information, systems, and services associated with mission and business functions throughout the system life cycle.

qualification Process of demonstrating whether an entity is capable of fulfilling specified requirements. [86]

quality assurance Part of quality management focused on providing confidence that quality requirements will be fulfilled. [78]

quality characteristic Inherent characteristic of a product, process, or system related to a requirement. [78]

quality management — Coordinated activities to direct and control an organization with regard to quality. [78]

reference monitor concept — An abstract model of the necessary and sufficient properties that must be achieved by any mechanism that performs an access mediation control function. [21] [37]

reference validation mechanism — An implementation of the reference monitor concept that validates each access to resources against a list of authorized accesses allowed. [37]

requirement — Statement that translates or expresses a need and its associated constraints and conditions. [31] A condition or capability that must be met or possessed by a system or system element to satisfy an agreement, standard, specification, or other formally imposed documents. [131]

requirements engineering — An interdisciplinary function that mediates between the domains of the acquirer and supplier to establish and maintain the requirements to be met by the system, software, or service of interest. [31]

Note: Requirements engineering is concerned with discovering, eliciting, developing, analyzing, verifying, validating, managing, communicating, and documenting requirements.

resource — Asset used or consumed during the execution of a process. [4]

Note 1: Includes diverse entities, such as funding, personnel, facilities, capital equipment, tools, and utilities, such as power, water, fuel, and communication infrastructures.

Note 2: Resources include those that are reusable, renewable, or consumable.

retirement — Withdrawal of active support by the operation and maintenance organization, partial or total replacement by a new system, or installation of an upgraded system. [4]

risk — Effect of uncertainty on objectives. [28]

Note 1: An effect is a deviation from the expected, positive or negative. A positive effect is also known as an opportunity.

Note 2: Objectives can have different aspects (i.e., financial, health and safety, and environmental goals) and can apply at different levels (i.e., strategic, organization-wide, project, product, and process).

Note 3: Risk is often characterized by reference to potential events and consequences or a combination of these.

Note 4: Risk is often expressed in terms of a combination of the consequences of an event (including changes in circumstances) and the associated likelihood of occurrence.

Note 5: Uncertainty is the state, even partial, of deficiency of information related to the understanding or knowledge of an event, its consequence, or likelihood.

risk analysis — Process to comprehend the nature of risk and to determine the level of risk. [28]

risk assessment — Overall process of risk identification, risk analysis, and risk evaluation. [28]

risk criteria — Terms of reference against which the significance of a risk is evaluated. [28]

risk evaluation — Process of comparing the results of risk analysis with risk criteria to determine whether the risk and/or its magnitude is/are acceptable or tolerable. [28]

risk identification — Process of finding, recognizing, and describing risks. [28]

risk management — Coordinated activities to direct and control an organization with regard to risk. [28]

risk tolerance — The organization or stakeholder’s readiness to bear the risk after risk treatment in order to achieve its objectives. [28]

Note: Risk tolerance can be influenced by legal or regulatory requirements.

risk treatment — Process to modify risk. [28]

safety — Expectation that a system does not, under defined conditions, lead to a state in which human life, health, property, or the environment is endangered. [86]

security — Freedom from those conditions that can cause the loss of assets with unacceptable consequences.

security architecture — A set of physical and logical security-relevant representations (i.e., views) of system architecture that conveys information about how the system is partitioned into security domains and makes use of security-relevant elements to enforce security policies within and between security domains based on how data and information must be protected.

Note: The security architecture reflects security domains, the placement of security-relevant elements within the security domains, the interconnections and trust relationships between the security-relevant elements, and the behavior and interactions between the security-relevant elements. The security architecture, like the system architecture, may be expressed at various levels of abstraction and with different scopes.

security design order of precedence — A design approach for minimizing the design basis for loss potential and using architectural features to provide structure for implementing engineered security features and devices.

security domain — Set of assets and resources subject to a common security policy. [85]

Note: A security domain is defined by rules (policy) for users, processes, systems, and services that apply to activities within the domain and activities with similar entities in other domains.

security function — The capability provided by the system or a system element. The capability may be expressed generally as a concept or specified precisely in requirements.

security mechanism — A device or method for achieving a security-relevant purpose.

security policy — A set of rules that governs all aspects of security-relevant system and system element behavior.

Note 1: System elements include technology, machine, and human elements.

Note 2: Rules can be stated at high levels of abstraction (e.g., an organizational policy that defines the acceptable behavior of employees in performing their mission and business functions) or at low levels of abstraction (e.g., an operating system policy that defines the acceptable behavior of executing processes and the use of resources by those processes).

security relevance — The functions or constraints that are relied upon to directly or indirectly meet protection needs.

Note: The term security relevance has been used to differentiate the role of system functions that singularly or in combination exhibit behavior, produce an outcome, or provide a capability to enforce authorized and intended system behavior or outcomes.

security requirement — A requirement that has security relevance.

security risk — The effect of uncertainty on objectives pertaining to asset loss and the associated consequences. [28]

Note: [28] defines risk as the effect of uncertainty on objectives. Furthermore, risk can be either positive or negative.

security service — A security capability or function provided by an entity.

security specification — The requirements for the security-relevant portion of the system.

Note: The security specification may be provided as a separate document or may be captured with a broader specification.

self-protection — The protection provided by an entity to ensure its own correct behavior and function despite adversity.

Note: While an entity would ideally be able to provide all the self-protection necessary, in practice entities are limited in the extent that they can provide for their own protection without depending on one or more other entities.

service — Performance of activities, work, or duties. [4]

Note 1: A service is self-contained, coherent, discrete, and can be composed of other services.

Note 2: A service is generally an intangible product.

situational awareness — Perception of elements in the system and/or environment and a comprehension of their meaning, which could include a projection of the future status of perceived elements and the uncertainty associated with that status. [87]

specification — An information item that identifies, in a complete, precise, verifiable manner, the requirements, design, behavior, or other expected characteristics of a system, service, or process. [128]

See security specification.

stage — Period within the life cycle of an entity that relates to the state of its description or realization. [4]

Note 1: As used in this document, stages relate to major progress and achievement milestones of the entity throughout its life cycle.

Note 2: Stages often overlap.

stakeholder — Individual or organization having a right, share, claim, or interest in a system or in its possession of characteristics that meet their needs and expectations. [4]

stakeholder (system) — Individual, team, organization, or classes thereof having an interest in a system. [71]

strength of function — Criterion expressing the minimum efforts assumed necessary to defeat the specified security behavior of an implemented security function by directly attacking its underlying security mechanisms.

Note 1: Strength of function has a prerequisite that assumes that the underlying security mechanisms are correctly implemented. The concept of strength of function may be equally applied to services or other capability-based abstraction provided by security mechanisms.

Note 2: The term robustness combines the concepts of assurance of correct implementation with strength of function to provide finer granularity in determining the trustworthiness of a system.

susceptibility — The inability to avoid adversity.

supplier — Organization or an individual that enters into an agreement with the acquirer for the supply of a product or service. [4]

Note 1: Other terms commonly used for supplier are contractor, producer, seller, or vendor.

Note 2: The acquirer and the supplier are sometimes part of the same organization.

system — An arrangement of parts or elements that together exhibit behavior or meaning that the individual constituents do not. Systems can be physical or conceptual, or a combination of both. [3] [4]

Note 1: A system is sometimes considered as a product or as the services that it provides.

Note 2: In practice, the interpretation of its meaning is frequently clarified by the use of an associative noun (e.g., aircraft system). Alternatively, the word “system” is substituted simply by a context-dependent synonym (e.g., aircraft), though this potentially obscures a system principles perspective.

Note 3: A complete system includes all associated equipment, facilities, material, computer programs, services, firmware, technical documentation, and personnel required for operations and support to the degree necessary for self-sufficient use in its intended environment.

system element — Member of a set of elements that constitute a system. [4]

Note: A system element is a discrete part of a system that can be implemented to fulfill specified requirements.

system of interest — System whose life cycle is under consideration. [4]

system of systems — System of interest whose system elements are themselves systems; typically, these entail large-scale interdisciplinary problems with multiple, heterogeneous, distributed systems. [15] Set of systems or system elements that interact to provide a unique capability that none of the constituent systems can accomplish on its own. [88]

system context — The specific system elements, boundaries, interconnections, interactions, and operational environment that define a system.