Chapter 1 Flashcards
Set of cohesive tasks within a process.
Activity
Security commensurate with the risk and the magnitude of harm resulting from the loss, misuse, or unauthorized access to or modification of information.
Adequate Security
An undesirable consequence associated with a loss.
Adverse Consequence
The process an organization employs to determine whether security controls are defined as system-specific, hybrid, or common.
Allocation
The process an organization employs to assign security controls to specific information system components responsible for providing a particular security capability (e.g., router, server, remote sensor, etc.).
Allocation
An analytical comparison or evaluation of proposed approaches to meet an objective.
Analysis of Alternatives
Can be applied to anything — from a large military acquisition decision to a decision between two products.
Analysis of Alternatives
The formal or informal process involves identifying key decision factors — such as lifecycle operations, support, training, sustainment costs, risks, and effectiveness— and assessing each option with respect to these factors.
Analysis of Alternatives
An analytical comparison if the operational effectiveness, cost, and risks of proposed materiel solutions to gaps and shortfalls in operational capability.
Analysis of Alternatives
Analyses that document the rationale for identifying/recommending a preferred solution or solutions to the identified shortfall.
Analysis of Alternatives
Can be triggered by threat changes, deficiencies, obsolescence of existing systems, or advances in technology.
Analysis of Alternatives
A software program hosted by an information system.
Application
A set of related physical and logical representations (i.e., views) of a system or a solution.
Architecture
Conveys information about system/solution elements, interconnections, relationships, and behavior at different levels of abstractions and with different scopes.
Architecture
Fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and the principles of its design and evaluation.
Architecture (System)
A work product used to express an architecture.
Architecture Description
Conventions, principles, and practices for the description of architecture established within a specific domain of application and/or community of stakeholders.
Architecture Framework
A method for evaluating architecture-level designs that considers multiple attributes including modifiability, security, performance, and reliability, to gain insight as to whether the fully described architecture will meet its requirements.
Architecture Trade-off Analysis
Identifies trade-off points among multiple attributes (e.g., modifiability, security, performance, reliability, etc.), facilitates communication among stakeholders (e.g., customer, developer, maintainer, etc.) from the perspective of each attribute, clarifies and refines requirements, and provides a framework for an ongoing, concurrent process of system design and analysis.
Architecture Trade-off Analysis
A work product expressing the architecture of a system from the perspective of specific system concerns.
Architecture View
The property of being genuine and being able to be verified and trusted; confidence in the validity of a transmission, a message, or a message originator.
Authenticity
Hardware, software, and relevant documentation for an information system at a given point in time.
Baseline
Formally approved version of a configuration item, regardless of media, formally designated and fixed at a specific time during the configuration item’s lifecycle.
Baseline
A documented set of specifications for an information system, or a configuration item within a system, that has been formally reviewed and agreed on at a given point in time, and which can be changed only through change control procedures.
Baseline Configuration
Physical or logical perimeter of a system.
Boundary
A set of instructions for a computer.
Code
System of communication in which arbitrary groups of letters, numbers, or symbols represent units if plain text of varying length.
Code
A system element.
Component
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.
Consequence
Factors that impose restrictions and limitations on the system or actual limitations associated with the use of the system.
Constraint
Prevention of damage to, protection of, and restoration of computers, electronic communications systems, electronic communication services, wire communication, and electronic communication, including information contained therein, to ensure its availability, integrity, authentication, confidentiality, and nonrepudiation.
Cybersecurity
A basic unit of information that has a unique meaning and subcategories (data items) of distinct value (e.g., gender, race, geographic location, etc.).
Data Element
The property that data has not been altered in an unauthorized manner and covers data in storage, during processing, and while in transit.
Data Integrity
A requirement that is implied or transformed from a higher-level requirement.
Derived Requirement
Cannot be assessed since they are not contained in any requirements baseline.
Derived Requirement
Must trace back to at least one higher level requirement.
Derived Requirement
Process of defining the system elements, interfaces, and other characteristics of a system of interest in accordance with the requirements and architecture.
Design
Analysis that is focused on determining the design approach that is best suited for implementing the elements, physical safeguards, and procedural measures of the system.
Design Trade-off Analysis
Includes the following considerations: whether technical elements, physical safeguards, or procedural measures are appropriate to implement the system security requirements; and whether acquiring an off-the-shelf product, accessing or developing a service, or custom development is appropriate to implement the system security requirements.
Design Trade-off Analysis
An environment or context that includes a set of system resources and a set of system entities that have the right to access the resources as defined by a common security policy, security model, or security architecture.
Domain
System that supports a system-of-interest during its lifecycle stages but does not necessarily contribute directly to its function during operation.
Enabling System
The individuals on the systems engineering team with security responsibilities, systems engineers that are part of the systems engineering team, or a combination thereof.
Engineering Team
Context determining the setting and circumstances of all influences upon a system.
Environment (System)
A network not controlled by the organization.
External Network
A mode of termination of system functions that prevents damage to specified system resources and system entities (i.e., specified data, property, and life) when a failure occurs or is detected in the system (but the failure might still cause a security compromise).
Fail Safe
A mode of termination of system functions that prevents loss of secure state when a failure occurs or is detected in the system (but the failure might still cause damage to some system resource or system entity).
Fail Secure
Selective termination of affected, non-essential system functions when a failure occurs or is detected in the system.
Fail Soft
Computer programs and data stored in hardware — typically in read-only memory (ROM) or programmable read-only memory (PROM) — such that the programs and data cannot be dynamically written or modified during execution of the programs.
Firmware
The material components of an information system.
Hardware
Aggregate of directives, regulations, and tules that prescribe how an organization manages, protects, and distributes information.
Information Security Policy
A discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information.
Information System (IS)
All components of an information system to be authorized for operation by an authorizing official, excluding separately authorized systems, to which the information system is connected.
Information System Boundary
The ability of an information system to continue to: (i) operate under adverse conditions or stress, even in a degraded or debilitated state, while maintaining essential operational capabilities; and (ii) recover to an effective operational posture in a time frame consistent with mission needs.
Information System Resilience
Individual assigned responsibility for conducting information system security engineering activities.
Information Systems Security Engineer (ISSE)
Process that captures and refines information security requirements and ensures their integration into information technology component products and information systems through purposeful security design or configuration.
Information Systems Security Engineering (ISSE)
Any equipment or interconnected system or subsystem of equipment that is used in the automatic acquisition, storage, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data or information by the executive agency.
Information Technology (IT)
Includes computers, ancillary equipment, software, firmware and similar products, services (including support services), and related resources.
Information Technology (IT)
Guarding against improper information modification or destruction; includes ensuring information non-repudiation and authenticity.
Integrity
Creations of the mind such as musical, literary, and artistic works; inventions; and symbols, names, images, and designs used in commerce, including copyrights, trademarks, patents, and related rights.
Intellectual Property
Common boundary between independent systems or modules where interactions take place.
Interface
A network where: (i) the establishment, maintenance, and provisioning of security controls are under the direct control of organizational employees or contractors; and (ii) cryptographic encapsulation or similar security technology provides the same effect.
Internal Network
A network that is typically organization-owned, yet may be organization-controlled while not being organization-owned.
Internal Network
Information system(s) implemented with a collection of interconnected components.
Network
Passive information system-related entity (e.g., devices, files, records, tables, processes, programs, domains) containing or receiving information.
Object
Access to this implies access to the information it contains.
Object
An entity of any size, complexity, or positioning within an organizational structure (e.g., a federal agency, or, as appropriate, any of its operational elements).
Organization
Statement that translates or expresses a need and its associated constraints and conditions.
Requirement
A condition or capability that must be met or possessed by a system or system element to satisfy a contract, standard, specification, or other formally imposed documents.
Requirement
The protective measures prescribed to meet the security requirements (e.g., confidentiality, integrity, and availability) specified for an information system.
Safeguards
May include security features, management constraints, personnel security, and security of physical structures, areas, and devices.
Safeguards
A condition that results from the establishment and maintenance of protective measures that enable an enterprise to perform its mission or critical functions despite risks posed by threats to its use of information systems.
Security
Measures may involve a combination of deterrence, avoidance, prevention, detection, recovery, and correction that should form part of the enterprise’s risk management approach.
Security
The set of minimum security controls defined for a low-impact, moderate-impact, or high-impact information system.
Security Control Baseline
The management, operational, and technical controls (i.e., safeguards or countermeasures) prescribed for an information system to protect the confidentiality, integrity, and availability of the system and its information.
Security Controls
A domain that implements a security policy and is administered by a single authority.
Security Domain
An interdisciplinary approach and means to enable the realization of secure systems.
Security Engineering
Focuses on defining customer needs, security protection requirements, and required functionality early in the systems development lifecycle, documenting requirements, and the proceeding with design, synthesis, and system validation while considering the complete problem.
Security Eningeering
A set of criteria for the provision of security services.
Security Policy
Requirements levied on an information system that are derived from applicable laws, executive orders, directives, policies, standards, instructions, regulations, procedures, or organizational mission/business case needs to ensure the confidentiality, integrity, and availability of the information being processed, stored, or transmitted.
Security Requirements
Description of the minimum requirements necessary for an information system to maintain an acceptable level of risk.
Security Requirements Baseline
Matrix documenting the system’s agreed-upon security requirements derived from all sources, the security features’ implementation details and schedule, and the resources required for assessment.
Security Requirements Traceability Matrix (SRTM)
Within a volume of time and space, the perception of an enterprise’s security posture and its threat environment; the comprehension/meaning of both taken together (risk); and the projection of their status into the near future.
Situational Awareness
Computer programs (stored and executed by computer hardware) and associated data ( stored in hardware) that may be dynamically written or modified during execution.
Software
Generally an individual, process, or device causing information to flow among objects or change to the system state.
Subject
Attacks that allow the adversary to infiltrate data, or manipulate information technology hardware, software, operating systems, peripherals (information technology products), or services at any point during the lifecycle.
Supply Chain Attacks
Often done using implants or other vulnerabilities inserted prior to installation.
Supply Chain Attacks
The risk that and adversary may sabotage, maliciously introduce unwanted function, or otherwise subvert the design, integrity, manufacturing, production, distribution, installation, operation, or maintenance of an item of a supply or a system so as to surveil, deny, disrupt, or otherwise degrade the function, use, or operation of a system.
Supply Chain Risk
A systematic approach for managing supply chain risk by identifying susceptibilities, vulnerabilities, and threats throughout the supply chain and developing mitigation strategies to combat those threats whether presented by the supplier, the supplies product and its subcomponents, or the supply chain (e.g., initial production, packaging, handling, storage, transport, mission operation, and disposal).
Supply Chain Risk Management (SCRM)
Any organized assembly of resources and procedures united and regulated by interaction or interdependence to accomplish a set of specific functions.
System
The scope of activities associated with a system, encompassing the system’s initiation, development and acquisition, implementation, operation and maintenance, and ultimately its disposal that instigates and other system initiation.
System Development Lifecycle (SDLC)
A specialty engineering field strongly related to systems engineering that applies scientific, engineering, and information assurance principles to deliver trustworthy systems that satisfy stakeholder requirements within their established risk tolerance.
Systems Security Engineering
The process by which a security control baseline is modified based on (i) the application of scoping guidance, (ii) the specification of compensating security controls, if needed, and (iii) the specification of organization-defined parameters in the security controls via explicit assignment and selection statements.
Tailoring
An intentional but unauthorized act resulting in the modification of a system, components of systems, its intended behavior, or data.
Tampering
Security controls (i.e., safeguards or countermeasures) for an information system that are primarily implemented and executed by the information system through mechanisms contained in the hardware, software, or firmware components of the system.
Technical Security Controls
Understanding the capabilities and intentions of adversaries as revealed by their targeting actions, also known as the modern threat space.
Systems Security Engineer Design Challenge
Identifying stakeholder assets and protection needs and provide protection countermeasures with the criticality of those assets and needs and the consequences of asset loss.
Systems Security Engineer Design Challenge
Understanding the growing complexity of systems to more effectively analyze, manage, and address the uncertainty associated with that complexity.
Systems Security Engineer Design Challenge
Integrating security requirements, functions, and services into mainstream management and technical processes within the lifecycle processes of systems
Systems Security Engineer Design Challenge
Building trustworthy secure systems capable of protecting stakeholder assets.
Systems Security Engineer Design Challenge
Not meeting a specified requirement, objective, or performance measure; adversity; disruption; hazard; threat; or bad things that happen.
System Failure
Intentional causing of system failure.
Forced system Failure
Unintentional causing of system failure.
Unforced System Failure
Engineering the security functions that provide system security capability.
Systems Security Engineer Role
Engineering the security-driven constraints for all system functions.
Systems Security Engineer Role
Engineering and advising for the protection of data, information, technology, methods, and assets associated with the system throughout its lifecycle.
Systems Security Engineer Role
The engineering effort includes such activities as concept exploration, analysis of alternatives, and preliminary or applied research to refine the concepts and/or feasibility of technologies employed.
New Systems
Engineering effort that is initiated during the concept and development stages of the system life cycle.
New Systems
The engineering effort occurs in response to adversity in the form of disruptions, hazards, and threats such as cyber-attacks, incidents, errors, accidents, faults, component failures, and natural disasters that diminish or prevent the system form achieving its design intent.
Reactive Modifications to Fielded Systems
Engineering effort that can occur during the production, utilization, or support stages of the system life cycle and may be performed concurrently with or independent of da-to-day operations.
Reactive Modifications to Fielded Systems
The engineering effort may enhance an existing capability, provide a new capability, or constitute a technology refresh of an existing capability.
Planned Upgrades to Fielded Systems
Engineering effort occurs during the production, utilization, and support stages of the system life cycle and is performed while sustaining day-to-day operations.
Planned Upgrades to Fielded Systems
The engineering effort that is carried out as if developing a new system with a system life cycle that is distinct from the life cycle of a fielded system.
Planned Upgrades to Fielded Systems that Result in New Systems
Engineering effort that is performed in a development environment that is independent of the fielded system.
Planned Upgrades to Fielded Systems that Result in New Systems
The engineering effort delivers a system that satisfies a security-dedicated need or provides a security-oriented purpose, and does so as a stand-alone system that may monitor or interact with other systems.
Security-dedicated or Security-purposed Systems
The engineering effort delivers a system that satisfies the need for real-time control of vehicles, industrial or utility processes, weapons, nuclear, or other special-purpose needs.
Dedicated or Special Purpose Systems (High Confidence)
The engineering effort occurs across a set of constituent systems, each system with its own stakeholders, primary purpose, and planned evolution.
Systems of Systems
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.
Evolution of Systems
The engineering effort removes system functions or services and associated system elements from operation, to include removal of the entire system, and may also include the transition of system functions and services to some other system.
Retirement of Systems
Engineering effort that occurs during the retirement stage of the system life cycle and may be carried out while sustaining day-to-day operations.
Retirement of Systems
Combination of interacting elements organized to achieve one or more stated purposes.
System
Member of a set of elements that constitute a system.
System Element
System whose life cycle is under consideration in the context of this International Standard.
System-of-interest
System that supports a system-of-interest during its life cycle stages but does not necessarily contribute directly to its function during operation.
Enabling System
System that interacts with the system-of-interest in its operational environment.
Other System
Focus of the engineering effort.
System-of-interest
Achieved only through sound, purposeful engineering informed by the specialty discipline of systems security engineering.
Adequate Security
Made explicit by ‘binding’ together the following: (i) defining asset loss and consequences as the primary target of security, (ii) establishing security as a protection control objective for the system, and (iii) recognizing that the achievement of the protection control objective is a system design problem that delivers trustworthy system function across all system elements.
Adequate Security
Results from the reasoned sum of all system protections (both active and passive protections) for all system execution modes (e.g., initialization, operation, maintenance, training, shutdown); for all system states (e.g., secure, nonsecure, normal, degraded, recovery); and for all transitions that occur between system states and between system execution modes.
Adequate Security
The security functions of the system that exhibit security protection behavior and therefore, have functional and performance attributes.
Active Security
Security functions that explicitly satisfy security requirements that address the behavior, utilization, and interaction of and among technology/machine, environment, human, and physical system elements.
Active Security
The environment for the execution and construction of all security functions (both active protection and general system functionality).
Passive Protection
Includes architecture, design, and the rules that govern behavior, interaction, and utilization.
Passive Protection
Can be achieved by defining clear security objectives and requirements.
Documenting Adequate Security
Often impacts performance or drives up the cost of hardware.
Security
Must understand the sensitivity of the data, technology, and assets that interact or are a part of the system being designed.
Systems Security Engineer
Must identify the sensitivity and proved recommendations to the team on how to protect the data while stored, processed, or transmitted.
Systems Security Engineer
Space where the SSE: (i) defines security objectives, (ii) defines security requirements, (iii) defines success measurements, (iv) defines lifecycle security concepts, and (v) produces evidence for security aspects of the problem.
Problem Context Space
Space where the SSE: (i) defines the security aspects, (ii) realizes the security aspects of the lifecycle security concepts, and (iii) produces evidence for security aspects of the solution.
Solution Context Space
Space where the SSE: (i) develops the assurance case for acceptable security and (ii) demonstrates the assurance case is satisfied.
Trustworthiness Context Space
Encompasses the acquisition and supply process.
Agreement Processes
Encompasses lifecycle model, infrastructure, portfolio, human resource, quality, and knowledge management.
Organizational Project Enabling Processes
Encompasses project planning, project assessment and control, decision management, risk management, configuration management, information management, measurement, and quality assurance.
Technical Management Processes
Encompasses business/mission analysis, stakeholder needs/requirements definition, system requirements definition, architectural definition, design definition, system analysis, implementation, integration, verification, transition, validation, operation, maintenance, and disposal.
Technical Processes
Includes concept, development, production, utilization, support, and retirement.
Lifecycle Stages
Includes agreement, organizational project-enabling, technical management, and technical processes.
System Lifecycle Processes
States that a system should have simple, well-defined interfaces and functions that provide a consistent and intuitive view of data and how it is managed.
Principle of Clear Abstractions
The elegance (e.g., clarity, simplicity, necessity, sufficiency) of the systems interfaces, combined with a precise definition of their functional behavior promotes ease of analysis, inspection, and testing as well as the correct and secure use of the system.
Principle of Clear Abstractions
Examples reflecting application of this include: (i) avoidance of redundant, unused interfaces, (ii) information hiding, and (iii) avoidance of semantic overloading of interfaces or their parameters (e.g., not using one function to provide different functionality, depending on how it is used).
Principle of Clear Abstractions
A design discipline to ensure that the internal representation of information in one system component is not visible to another system component invoking or calling the first component, such that the published abstraction is not influenced by how the data may be managed internally.
Information Hiding
Serves to isolate functions and related data structures into well-defined logical units.
Modularity
Allows the relationships of well-defined logical units to be better understood, so that dependencies are clear and undesired complexity can be avoided.
Layering
Includes the following: (i) allocation of policies to systems in a network, (ii) allocation of system policies to layers, (iii) separation of system applications into processes with distinct address spaces, and (iv) separation of processes into subjects with distinct privileges based on hardware-supported privilege domains.
Security-informed Modular Decomposition
Provide clarity and make it possible to understand the structure of a system.
Modularity and Layering
Security architectures constructed through the application of multiple mechanisms to create a series of barriers to prevent, delay, or deter an attack by an adversary.
Defense in Depth
States that the calling, synchronization, and other dependencies in the system should be partially ordered (e.g., some layers being self-contained and not dependent on lower layers).
Partially Ordered Dependencies
Often the predominant security function of secure systems.
Mediation of Access to System Resources
States that policy-enforcement mechanisms utilize the least common mechanisms available when satisfying stakeholder requirements.
Principle of Efficiently Mediated Access
States that no computer resource should be shared between system components (e.g., subjects, processes, functions) unless it is absolutely necessary to do so.
Principle of Minimized Sharing
In order to protect user-domain resources from arbitrary active entities, no resource should be shared unless that sharing has been explicitly requested and granted.
Principle of Minimized Sharing
Must be carefully designed to avoid performance and covert storage and timing-channel problems.
Internal Sharing
States that the system design should be as small and simple as possible.
Principle of Reduced Complexity
Contributes to the ability of system developers to understand the correctness and completeness of system security functions and facilitates identification of potential vulnerabilities.
Principle of Reduced Complexity
States that a system should be developed to facilitate the maintenance of its security properties when there are changes to its functionality structure, interfaces, and interconnections (i.e., system architecture) or its functionality configuration (i.e., security policy enforcement).
Principle of Secure Evolvability
The benefits of this principle include reduced vendor lifecycle costs; reduced cost of ownership; improved system security; more effective management of security risk; and less risk uncertainty.
Principle of Secure Evolvability
Facilitates maintenance, reduces downtime, and allows for new technology to be brought to the existing design without needing to replace the entire system.
Principle of Secure Evolvability
States that a component must be trustworthy to at least a level commensurate with the security dependencies it supports (i.e., how much it is trusted to perform its security functions by other components).
Principle of Trusted Components
This principle enables the composition of components such that trustworthiness is not inadvertently diminished and where consequently the trues is not misplaced.
Principle of Trusted Components
This principle is particularly relevant when considering systems and components which there are complex chains of trust dependencies.
Principle of Trusted Components
This principle also applies to a compound component that consists of several subcomponents (e.g., a subsystem), which may have varying levels of trustworthiness.
Principle of Trusted Components
States that the security dependencies in a system will form a partial ordering if they preserve the principle of trusted components.
Principle of Hierarchical Trust
The system takes on the trust level of its least trustworthy component.
Principle of Hierarchical Trust
States that the degree of protection provided to a component must be commensurate with its trustworthiness.
Principle of Inverse Modification Threshold
As the trust placed in a component increases, the protection against unauthorized modification of the component should also increase to the same degree.
Principle of Inverse Modification Threshold
States that a component need not be protected from more trustworthy components.
Principle of Hierarchical Protection
The most trusted component must protect itself from all other components.
Principle of Hierarchical Protection
States that the system should not have extraneous trusted components.
Principle of Minimized Security Elements
To reduce cost and decrease the complexity of the security analysis, a system should contain as few trustworthy components as possible.
Principle of Minimized Security Elements
States that each component should be allocated sufficient privileges to accomplish its specific functions, but no more.
Principle of Least Privilege
Limits the scope of the component’s actions, which has two desirable effects: (i) the security impact of failure, corruption, or misuse of the component will have a minimized impact; and (ii) the security analysis of the component will be simplified.
Principle of Least Privilege
The scope of a given module or component should include only those system elements that are necessary for its functionality, and that the modes (e.g., read, write) by which the elements are accessed should be minimal.
Internal Least Privilege
The construction of modules so that only the elements encapsulated by the module are directly operated upon by the functions within the module.
Internal Least Privilege
States that system designers should consider requiring multiple authorized entities to provide consent before a highly critical operation or access to highly sensitive data, information, or resources is allowed to proceed.
Principle of Predicate Permission
Design options include such a mechanism that require simultaneous action or a sequence of operations where each successive action is enabled by some prior action, but no single individual is able to enable more than one action.
Principle of Predicate Permission
States that systems should minimize their reliance on other systems for their own trustworthiness.
Principle of Self-reliant Trustworthiness
A benefit to this principle is that the isolation of a system will make it less vulnerable to attack.
Principle of Self-reliant Trustworthiness
States that the composition of distributed components that enforce the same security policy should result in a system that enforces that policy at least as well as the individual components do.
Principle of Secure Distributed Composition
States that when composing a system where there is a potential threat to communications between components (i.e., the interconnections between components), each communication channel must be trustworthy to a level commensurate with the security dependencies it supports (i.e., how much it is trusted by other components to perform its security functions).
Principle of Trusted Communication Channels
Achieved by a combination of restricting access to the communication channel (to help ensure an acceptable match in the trustworthiness of the endpoints involved in the communication) and employing end-to-end protections involved in the data transmitted over the communication channel (to help protect against interception and modification, and to further increase the overall assurance of proper end-to-end communication).
Principle of Trusted Communication Channels
Technical process whose purpose is to define the business or mission problem or opportunity, characterize the solution space, and determine potential solution classes that could address a problem or take advantage of an opportunity.
Business or Mission Analysis
The security aspects of the problem or opportunity space are deinfed
Business or Mission Analysis Outcome
The security aspects of the solution space are characterized.
Business or Mission Analysis Outcome
The concerns, constraints, limitations, and other security considerations that can affect potential solutions are defined.
Business or Mission Analysis Outcome
Preliminary concepts for the security aspects of system lifecycle concepts are defined.
Business or Mission Analysis Outcome
Alternative solution classes that take into account security objectives, considerations, concerns, limitations, and constraints, are identified.
Business or Mission Analysis Outcome
Candidate and preferred alternative solution classes are identified, analyzed, and selected to explicitly account for security objectives, considerations, concerns, limitations, and constraints.
Business or Mission Analysis Outcome
Any enabling systems or services needed to achieve the security aspects of business or mission analysis are available.
Business or Mission Analysis Outcome
Security-relevant traceability of the business or mission problems and opportunities and the preferred alternative solution classes are established.
Business or Mission Analysis Outcome
Business or mission analysis activity that focuses on doing research to understand the mission as the systems security engineering stakeholder.
Prepare for the Security Aspects of Business Analysis
Business or mission analysis activity that focuses on doing research to determine which solution best meets mission objectives.
Evaluate and Select Solution Classes
Business or mission analysis activity that focuses on documenting the solution.
Manage the Security Aspects of Business or Mission Analysis
Business or mission analysis activity that focuses on doing research to identify potential solution classes.
Characterize the Security Aspects of the Solution
Technical process whose purpose is to define the stakeholder requirements for a system that can provide the capabilities needed by users and other stakeholders in a defined environment.
Stakeholder Needs and Requirements Definition
The security interest and concerns of stakeholders of the system are identified.
Stakeholder Needs and Requirements Definition Outcome
Required security characteristics and security context for the secure use of capabilities for all system lifecycle concepts in all system lifecycle stages are defined.
Stakeholder Needs and Requirements Definition Outcome
Stakeholder assets and assets classes are identified.
Stakeholder Needs and Requirements Definition Outcome
Assest susceptibility to adversity and uncertianity is determined.
Stakeholder Needs and Requirements Definition Outcome
Asset protection priorities and protection assurances are determined.
Stakeholder Needs and Requirements Definition Outcome
Stakeholder protection needs are defined and prioritized.
Stakeholder Needs and Requirements Definition Outcome
Security-driven and security-informed constraints on a system are identified.
Stakeholder Needs and Requirements Definition Outcome
Security-oriented performance measures are defined.
Stakeholder Needs and Requirements Definition Outcome
The security interest and concerns of stakeholders of the system are identified.
Stakeholder Needs and Requirements Outcome
Stakeholder protection needs are transformed into stakeholder security requirements.
Stakeholder Needs and Requirements Definition Outcome
Stakeholder agreement that their protection needs and expectations are adequately reflected in the security requirements is achieved.
Stakeholder Needs and Requirements Definition Outcome
Any enabling systems or services needed to support the security aspects of stakeholder needs and requirements definition are available.
Stakeholder Needs and Requirements Definition Outcome
Asset protection data associated with protection needs and stakeholder security requirements is recorded as part of the system requirements.
Stakeholder Needs and Requirements Definition Outcome
Traceability of stakeholder security requirements, stakeholder protection needs, and asset protection data is established.
Stakeholder Needs and Requirements Definition Outcome
Stakeholder needs and requirements definition activity that focuses on identification of all stakeholders throughout the entire business or mission lifecycle that have a security interest.
Prepare for Stakeholder Protection Needs and Security Requirements Definition
Stakeholder needs and requirements definition activity that focuses on documenting and prioritizing assets.
Define Stakeholder Protection Needs
Stakeholder needs and requirements definition activity that focuses on turning stakeholder, system, and trades perspective needs into security requirements and security policy.
Transform Stakeholder Protection Needs into Security Requirements
Stakeholder needs and requirements definition activity that focuses on reviewing stakeholder requirements and resolving identified issues.
Analyze Stakeholder Security Requirements
Technical process whose purpose is to generate system architecture alternatives, to select on or more alternatives that frame stakeholder concerns and meet system requirements, and to express this in a set of consistent views.
Architectural Definition
Stakeholder security concerns are addressed by the system architecture.
Architectural Definition Outcome
The concept of secure function for the system at the architecture level is defined.
Architectural Definition Outcome
Security viewpoints, views, and models of the system architecture are developed.
Architectural Definition Outcome
Security context, domains, boundaries, and external interfaces of the system are defined.
Architectural Definition Outcome
Security concepts, properties, characteristics, functions, behavior, or constraints are allocated to architectural elements.
Architectural Definition Outcome
Security-relevant system elements and their interfaces are identified.
Architectural Definition Outcome
The security aspects of candidate system architectures are analyzed and assessed.
Architectural Definition Outcome
Alignment of the architecture with the system security requirements and security design characteristics is achieved.
Architectural Definition Outcome
Any enabling systems or services needed for the security aspects of the architectural definition are available.
Architectural Definition Outcome
Traceability of architecture elements to stakeholder and system security requirements is established.
Architectural Definition Outcome
Candidate security-related architecture metrics are identified.
Architectural Definition Outcome
Architecture definition activity that focuses on identifying what impacts the security aspects of the system architecture and stakeholder concerns.
Prepare for Architectural Definition from the Security Standpoint
Architecture definition activity that focuses on gathering relevant documentation and identifying key drivers that may impact the architecture.
Develop Security Viewpoints of the Architecture
Architecture definition activity that focuses on visualizing the security concepts and functionality important to stakeholders and where they are within the architecture.
Develop Security Models and Security Aspects of Candidate Architectures
Architecture definition activity that focuses on combining of system architecture from other stakeholders with the security architecture.
Related Security Views of the Architecture to the Design
Architecture definition activity that focuses on assessing candidate architectures and deciding on one to establish as the baseline architecture.
Select Candidate Architecture
Architecture definition activity that focuses on identifying the architectural governance approach and includes documenting applicable processes or laws, and who must approve the architecture.
Manage the Security View of the Selected Architecture
Technical process whose purpose is to provide sufficient detailed data and information about the system and its elements to enable the implementation consistent with architectural entities as defined in models and views of the system architecture.
Design Definition
Security design characteristics of each system element are defined.
Design Definition Outcome
System security requirements are allocated to system elements.
Design Definition Outcome
Design enablers necessary for the security aspects of design definition are selected or defined.
Design Definition Outcome
Security interfaces and security aspects of interfaces between system elements composing the system are defined or refined.
Design Definition Outcome
Security-driven design alternatives for system elements are assessed.
Design Definition Outcome
Design artifacts that include security considerations and constraints are developed.
Design Definition Outcome
Any enabling systems or services needed for the security aspects of design definition are available.
Design Definition Outcome
Traceability of security design characteristics to the architectureal entities of the system architecture is established.
Design Definition Outcome
Candidate security-related design metrics are identified.
Design Definition Outcome
Design definition activity that focuses on determining what secure functions will take place where and which security technology is required for each system element.
Prepare for Security Design Definition
Design definition activity that focuses on transforming security architecture elements into security design characteristics.
Establish Security Design Characteristics and Enablers for Each System Element
Design definition activity that focuses on identifying and assessing non-developmental items (NDI).
Asses the Alternatives for Obtaining Security-relevant System Elements
Components that already exist that can be incorporated into the design to fulfill a security function or capability (e.g., COTS).
Non-developmental Items
Technical process whose purpose is to provide a rigorous basis of data and information for technical understanding to aid decision making across the life cycle.
System Analysis
The security aspects of system analysis needs are identified.
System Analysis Outcomes
Assumptions and results related to the security aspects of system analysis are identified and validated.
System Analysis Outcomes
System security analysis results are provided for decisions.
System Analysis Outcomes
Any enabling systems or services needed for the security aspects of syste analysis are available.
System Analysis Outcomes
Traceability of system security analysis results is established.
System Analysis Outcomes
System analysis activity that focuses on the preparation for a system design review by pulling together all the artifacts relevant to the design to justify the design decisions made thus far.
Prepare for the Security Aspects of System Analysis
System analysis activity that focuses on analysis for quality and validity, reviewing and validating the assumptions associated with the security design.
Perform the Security Aspects of System Analysis
System analysis activity that focuses on checking the documentation to make sure the traceability of the security design aspects and the outputs of the analysis are recorded.
Manage the Security Aspects of System Analysis.
System analysis activity during which a formal design review would take place.
Perform the Security Aspects of System Analysis
Technical process whose purpose is to realize a specified system element.
Implementation
The security aspects of the implementation strategy are developed.
Implementation Outcome
The security aspects of implementation that constrain the requirements, architecture, or design are identified.
Implementation Outcome
A security-relevant or security-informed system element is realized.
Implementation Outcome
System elemetns are securely packaged and stored.
Implementation Outcome
Any enabling systems or services needed for the security aspects of implementation are available.
Implementation Outcome
Traceability of the security aspects of the implemented system elements is established.
Implementation Outcome
Implementation activity that focuses on documenting the implementation strategy and sharing it with stakeholders with an emphasis on design constraints from security aspects.
Prepare for the Security Aspects of Implementation
Implementation activity that focuses on refining implementation procedures and developing training materials for users.
Perform the Security Aspects Implementation
Implementation activity that focuses on documenting the results of the implementation and any issues that are encountered, including the security aspects implemented on a particular element.
Manage the Results of the Security Aspects Implementation
Technical process whose purpose is to synthesize a set of system elements into a realized system (product or service) that satisfies system requirements, architecture, and design.
Integration
The security aspects of the integration strategy are developed.
Integration Outcome
The security-driven integration constraints that influence requirements, architecture, design, orinterfaces and interactions are identified.
Integration Outcome
An approach and checkpoints for the correct secure operation of the assembled interfaces, interactions, behavior, and system functions are developed.
Integration Outcome
Any enabling systems or services needed to achieve the security aspects of integration are available.
Integration Outcome
A trustworthy secure system composed of implemented system elements is integrated.
Integration Outcome
The security behavior and interactions between interfaces of implemented system elements are checked.
Integration Outcome
The security behavior and interactions between the system and the external environment are checked.
Integration Outcome
The security aspects of integration results and security anomalies are identified.
Integration Outcome
Traceability of the security aspects of the integrated system elements is established.
Integration Outcome
Integration activity that focuses on developing the integration strategy and identifying any constraints resulting from integration.
Prepare for the Security Aspects of Integration
Integration activity that focuses on obtaining securely configured system elements and assembling them into the system.
Perform the Security Aspects of Integration
Integration activity that focuses on recording security aspects and anomalies discovered during integration and documenting security-relevant data as a security artifact.
Manage Results of the Seucrity Aspects of Integration
Technical process whose purpose is to provide objective evidence that a system or system element fulfills its specified requirements and characteristics.
Verification
The security aspects of the verification strategy are developed.
Verification Outcome
The security aspects of verification that constrain system requirements, architecture, or design are identified.
Verification Outcome
Any enabling systems or services needed to achieve the security aspects of verification are available.
Verification Outcome
The security requirements and security characteristics of the system or system element are verified.
Verification Outcome
Security-driven data providing information for corrective actions is reported.
Verification Outcome
Evidence that the realized system satisfies the system security requirements, security views of the architecture, and security design is provided.
Verification Outcome
The security aspects of verification results and security anomalies are identified.
Verification Outcome
Traceability of the security aspects of the verified system elements is established.
Verification Outcome
Verification activity that focuses on identifying the scope and strategy of the verification effort.
Prepare for the Security Aspects of Verification
A type of assessment method that is characterized by the
process of checking, inspecting, reviewing, observing, studying,
or analyzing one or more assessment objects to facilitate
understanding, achieve clarification, or obtain evidence, the results of which are used to support the determination of
security control or privacy control effectiveness over time.
Examine
A type of assessment method that is characterized by the
process of conducting discussions with individuals or groups within an organization to facilitate understanding, achieve
clarification, or lead to the location of evidence, the results of which are used to support the determination of security control and privacy control effectiveness over time.
Interview
A type of assessment method that is characterized by the
process of exercising one or more assessment objects under
specified conditions to compare actual with expected behavior,
the results of which are used to support the determination of
security control or privacy control effectiveness over time.
Test
Verification activity that focuses on developing and performing the test procedures for verification of the security aspects of the design.
Perform Security-focused Verification
Verification activity that focuses on recording the results and anomalies found during verification.
Manage Results of Security-focused Verification
Technical process whose purpose is to establish a capability for a system to provide services specified by stakeholder requirements in the operational environment.
Transition
The security aspects of the transition strategy are developed.
Transition Outcome
The security aspects of transition that constrain system requirements, architecture, or design are identified.
Transition Outcome
Any enabling systems or services needed to achieve the security aspects of transition are available.
Transition Outcome
The preparation of the operational site includes its security aspects.
Transition Outcome
The system and its enabling systems are securely installed in their operational environment and are capable of delivering the specified security functions and exhibiting secure behavior and characteristics.
Transition Outcome
Individuals involved with the operation, sustainment, and support of the system are trained in the system security capabilities and limitations.
Transition Outcome
Security-relevant transition results and anomalies are identified.
Transition Outcome
The installed system is activated and ready for operation in consideration of security-relevant capability, constraints, limitations, and identified anomalies.
Transition Outcome
Traceability of the security aspects of the transitioned elements is established.
Transition Outcome
Transition activity that focuses on developing the transition strategy and identifying the site, constraints, and training relevant to the transition.
Prepare of the security Aspects of Transition
Transition activity that focuses on delivering the system for installation, providing security training, and demonstrating that system and security functions meet requirements.
Perform the Security Aspects of Transition
Transition activity that focuses on recording anomalies, security aspects, operational incidents, and problems.
Manage Results of the Security Aspects of Transition
Technical process whose purpose is to provide objective evidence that the system, when in use, fulfills its business or mission objectives and stakeholder requirements, achieving its intended use in its intended operational environment.
Validation
The security aspects of the validation strategy are developed.
Validation Outcome
Validation criteria for stakeholder security requirements are defined.
Validation Outcome
The availability of security services required by stakeholders is confirmed.
Validation Outcome
The security aspects of validation that constrain requirements, architecture, or design are identified.
Validation Outcome
The security aspects of the system or system element are validated.
Validation Outcome
Any enabling systems or services needed to achieve the security aspects of validation are available.
Validation Outcome
Security-focused validation results and security anomalies are identified.
Validation Outcome
Evidence that the realized system or system elements satisfies stakeholder protection needs is provided.
Validation Outcome
Traceability of the validated security-relevant system elements is established.
Validation Outcome
Validation activity that focuses on developing the scope and strategy of validation actions.
Prepare for the Security Aspects of Validation
Validation activity that focuses on developing and performing procedures.
Perform the Security Aspects of Validation
Validation activity that focuses on recording security aspects and security anomalies into the formal body of evidence.
Manage Results of the Security Aspects for Validation
Techincal process whose purpose is to use the system to deliver its services.
Operation
The security aspects of the operation strategy are developed.
Operation Outcome
The security aspects of operation that constrain system requirements, architecture, or design are identified.
Operation Outcome
Any enabling systems or services needed to support the secure operation of the system are available.
Operation Outcome
Trained and qualified personnel capable of securely operating the system are available.
Operation Outcome
System services that meet stakeholder security requirements are delivered.
Operation Outcome
The security aspects of system performance during operation are monitored.
Operation Outcome
Traceability of the security aspects of operations elements is established.
Operation Outcome
Security support to the customer is provided.
Operation Outcome
Operation activity that focuses on developing the scope and strategy of operation actions.
Perpare for Secure Operation
Operation activity that focuses on the secure use of the system as intended in the intended environment.
Perform Secure Operation
Operation activity that focuses on recording the results and incidents.
Manage Results of Secure Operation
Operation activity that focuses on documenting customer requests for support and providing assistance to customers.
Support Security Needs of Customers
Technical Process whose purpose is to sustain the capability of the system to provide a service.
Maintenace
The security aspects of the maintenance strategy are developed.
Maintenace Outcome
The security aspects of maintenance and logistics that constrain system requirements, architecture, or design are identified.
Maintenace Outcome
Any enabling systems or services needed to support the security aspects of system maintenance and logistics are available.
Maintenace Outcome
Replacement, repaired, or modified system elements are available in consideration of their security aspects.
Maintenace Outcome
The need for changes to address security-relevant corrective, perfective, or adaptive maintenance is reported.
Maintenace Outcome
Security-relevant aspects, failure, and lifetime data, including associated costs, are determined.
Maintenace Outcome
Traceability of the security aspects of the maintained elements is established.
Maintenace Outcome
Maintenance activity that focuses on defining the maintenance strategy and identifying system constraints and trade spaces.
Prepare for the Security Aspects of Maintenance
Maintenance activity that focuses on reviewing incident and problem reports and implementing system restoration actions or preventative maintenance.
Perform the Security Aspects of Maintenance
Maintenance activity that focuses on acquisition and operational logistics.
Perform the Security Aspects of Logistics Support
Maintenance activity that focuses on recording security aspects and incidents encountered while performing maintenance and logistics.
Manage Results of the Seucrity Aspects of Mainteance and Logistics
Technical process whose purpose is to end the existence of a system element or system for a specified intended use, appropriately handle replaced or retired elements, and to properly attend to identified critical disposal needs (e.g., per an agreement, per organizational policy, or for environment, legal, safety, security aspects).
Disposal
The security aspects of the disposal strategy are developed.
Disposal Outcome
The security aspects of disposal that constrain system requirements, architecture, or design are identified.
Disposal Outcome
Any enabling systems or services needed to support the security aspects of disposal are available.
Disposal Outcome
System elements are securely removed from service, destroyed, stored, reclaimed, or recycled.
Disposal Outcome
The environment is returned to its original secure or agreed-upon secure state.
Disposal Outcome
Records of secure disposal actions and analysis are available.
Disposal Outcome
Disposal activity that focuses on developing the disposal strategy and identifying any required support services or secure storage.
Prepare for the Security Aspects of Disposal
Disposal activity that focuses on removing impacted systems, system elements, or operating staff.
Perform the Security Aspects of Disposal
Disposal activity that focuses on confirming that no unresolved factors exist and restoring the environment.
Manage Results of the Security Aspects for Disposal
The only organizational official that can accept the security and privacy risk to organizational operations, organizational assets, and individuals.
Authorization Official
Provides a set of well-defined rules that determines aspects of the behavior, interactions, and outcomes of system elements that are deemed secure.
Security Policy
Is enforced individually and in combination by human, physical and automated system elements.
Security Policy
Rules that govern access to, operations on, and disclosure of system elements.
Confidentiality
Rules that govern the modification and destruction of system elements and that govern the manner in which system elements can be manipulated.
Integrity
Rules that govern the presence, accessibility, readiness, and continuity of service of system elements.
Availability
Include a statement of intent to protect identified assets within the specific scope of stakeholder responsibility and security loss and risk concerns.
Security Policy Objectives
Identify the assets to be protected and scope of protection.
Security Policy Objectives
The set of laws, rules, and practices that regulate how an organization manages, protects, and distributes its assets to achieve specified security policy objectives.
Organizational Security Policy
Specifies what a system with security policy enforcement responsibility is expected to do.
System Security Policy
The set of restrictions and properties that to the enforcement of at specifies how a system enforces or contributes to the enforcement of an organizational security policy.
System Security Policy
The use of open or public designs for system security that do not rely on secret or proprietary design elements.
Open Design Concept
Advantages of this software design concept are low cost and customization.
Open Design Concept
Involves the development of software for which the organization or other licensed entity is the sole owner.
Proprietary Design Concept
Lifecycle model that describes each activity as a sequential top-down series of independent steps.
Waterfall/Predictive Model
Lifecycle model commonly seen in the execution of large systems engineering projects and has a sequential progression from project definition, through implementation, and to project test and integration.
V Model
Lifecycle model used to effectively manage disruptive technology and is focus on rapid and transparent feedback loops with the customer.
Agile/Iterative Model
This simple model compares the uncertainty of requirements with the technical degree of uncertainty in a project.
Uncertainty and Complexity Model
When tasks and activities to complete a project appear to have low uncertainty requirements in requirements definition and in technical uncertainty.
Simple Projects
When tasks and activities to complete a project appear to have increased uncertainty requirements in requirements definition and in technical uncertainty.
Complex Projects
When tasks and activities to complete a project appear to have high uncertainty requirements in requirements definition and in technical uncertainty.
Chaotic Projects
Lifecycle that works well on projects where the requirements and technical delivery have low uncertainty.
Waterfall/Predictive Lifecycles
Lifecycle that wors well on projects where the customer may not know exactly what they want for a finished product.
Iterative Lifecycles
Lifecycle that provides finished deliverables that the customer can both review and use immediately; focus is on speed.
Incremental Lifecycles
Lifecycle that is a combination of iterative and incremental lifecycle approaches; delivers highest value work first.
Agile Lifecycles
Lifecycle that develops an initial capability is built out to meet current needs and future needs are projected and aligned strategically with future increments.
Incremental Lifecycles
Agile team member that contributes to the entire set of skills necessary to produce a working product.
Cross-functional Team Member
Agile team member that guides product design and delivery.
Product Owner
Agile team member that manages the production of the working product.
Team Facailitator
Chart that shows number of features completed, number of features remaining, and new features added to the project.
Agile Burndown Chart
Easy to understand and provide a rigid clarity and clearly defined structure.
Waterfall Model Pros
Difficult to manage under complexity, assumes all requirements can be defined in advance, and is difficult to insert new technology.
Waterfall Model Cons
Easy to bring in new technology during prototype and proof-of-concept iterations, continuous customer feedback loops enable higher customer satisfaction, and wasteful development cycles are minimized.
Agile Model Pros
Needs a disciplined and experienced product owner and products may be delivered without appropriate security measures.
Agile Model Cons
This lifecycle has fixed requirements, activities are performed once, single products are delivered, and the goal is cost management.
Predictive Lifecycle
This lifecycle has dynamic requirements, activates are repeated until customer expectations are met, single products are delivered, and the goal is correctness of the solution.
Iterative Lifeccle
This lifecycle has dynamic requirements, activates are broken into smaller increments and performed once per increment, frequent small products are delivered, and the goal is speed.
Incremental Lifecycle
This lifecycle has dynamic requirements, activates are repeated until customer expectations are met, frequent small products are delivered, and the goal is customer satisfaction and value.
Agile Lifecycle
Document that contains the three key principles for SSE projects: (i) keep the problem and solution spaces separate, (ii) the problem space is defined by the customer’s mission or business needs, and (iii) the systems engineer and information systems security engineer define the solution space, drive by the problem space.
Information Assurance Technical Framework (IATF)
This process has the following activities: (i) discover needs, (ii) define system requirements, (iii) define system architecture, (iv) develop detailed design, and (v) implement the system.
The Information Systems Security Engineering Process
Technical management process whose purpose is to produce and coordinate effective and workable plans.
Project Planning
Security objectives and the security aspects of project plans are defined.
Project Planning Outcome
Systems security engineering roles, responsibilities, accountabilities, and authorities are defined.
Project Planning Outcome
Resources and services necessary to achieve the security objectives of the project are formally requested and committed.
Project Planning Outcome
Plans for the execution of the security aspects of the project are activated.
Project Planning Outcome
Define the security aspects of the project.
Project Planning Activity
Plan the security aspects of the project and technical management.
Project Planning Activity
Activate the security aspects of the project.
Project Planning Activity
Technical management process whose purpose is to assess if the plans are aligned and feasible; determine the status of the project, technical and process performance; and direct execution to help ensure that the performance is according to plans and schedule, within projected budgets, to satisfy technical objectives.
Project Assessment and Control
The security aspects of performance measures or assessment results are available.
Project Assessment and Control Outcome
The adequacy of security-relevant roles, responsibilities, accountabilities, and authorities is assessed.
Project Assessment and Control Outcome
The adequacy of resources allocated to the security aspects of the project is assessed.
Project Assessment and Control Outcome
The security aspects of technical progress reviews are performed.
Project Assessment and Control Outcome
Deviations in the security aspects of project performance from plans are investigated and analyzed.
Project Assessment and Control Outcome
Lessons learned are recorded to help inform and guide future projects and activities within projects.
Project Assessment and Control Outcome
Affected stakeholders are informed of the security aspects of project status.
Project Assessment and Control Outcome
Corrective action is defined and directed, when the security aspects of project achievement are not meeting targets.
Project Assessment and Control Outcome
The security aspects of project replanning are initiated, as necessary.
Project Assessment and Control Outcome
The security aspects of project action to progress (or not) from one scheduled milestone or event to the next is authorized.
Project Assessment and Control Outcome
Project security objectives are achieved.
Project Assessment and Control Outcome
Plan for the security aspects of project assessment and control.
Project Assessment and Control Activity
Assess the security aspects of the project.
Project Assessment and Control Activity
Control the security aspects of the project.
Project Assessment and Control Activity
Technical management process whose purpose is to provide a structured, analytical framework for objectively identifying, characterizing, and evaluating a set of alternatives for a decision at any point in the lifecycle and select the most beneficial course of action.
Decision Management
The most important systems security engineering decisions that must typically be made within the project.
Trade-space/Trade-off Decisions
The security aspects of the decision management strategy are established.
Decision Management Outcome
The security aspects of decisions requiring alternative analysis are identified.
Decision Management Outcome
Security-based decisions requiring alternative analysis are identified.
Decision Management Outcome
The security aspects of alternative courses of action are identified and evaluated.
Decision Management Outcome
A preferred course of action informed by or driven by security considerations is selected.
Decision Management Outcome
The security aspects of a resolution, of the decision rationale, and of the assumptions are identified.
Decision Management Outcome
Prepare for decisions with security implications.
Decision Management Activity
Analyze the security aspects of decision information.
Decision Management Activity
Make and manage security decisions.
Decision Management Activity
Technical management process whose purpose is to identify, analyze, treat, and monitor the risks continually.
Risk Management
The security aspects of the risk management strategy are defined.
Risk Management Outcome
Security risks are identified and analyzed.
Risk Management Outcome
Security risk treatment options are identified, prioritized, and selected.
Risk Management Outcome
Appropriate security risk treatment is implemented.
Risk Management Outcome
Security risks are evaluated on an ongoing basis to assess changes in status and progress in security risk treatment.
Risk Management Outcome
Security risks are recorded and maintained in the risk profile.
Risk Management Outcome
Plan security risk management.
Risk Management Activity
Manage the security aspects of the risk profile.
Risk Management Activity
Analyze security risk.
Risk Management Activity
Treat security risk.
Risk Management Activity
Monitor security risk.
Risk Management Activity
Technical management process whose purpose is to manage and control system elements and configurations over the life cycle.
Configuration Management
The security aspects of the configuration management strategy are defined.
Configuration Management Outcome
The security aspects of configuration items are identified and managed.
Configuration Management Outcome
Security criteria are included in configuration baselines
Configuration Management Outcome
Changes to items under configuration management are securely controlled.
Configuration Management Outcome
Security aspects are included in configuration status information.
Configuration Management Outcome
Completed configuration audits include security criteria.
Configuration Management Outcome
The security aspects of system releases and deliveries are controlled and approved.
Configuration Management Outcome
Plan for the security aspects of configuration management.
Configuration Management Activity
Perform the security aspects of configuration identification.
Configuration Management Activity
Perform security configuration change management.
Configuration Management Activity
Perform security configuration status accounting.
Configuration Management Activity
Perform security configuration evaluation.
Configuration Management Activity
Perform the security aspects of release control.
Configuration Management Activity
Technical management process whose purpose is to generate, obtain, confirm, transform, retain, retrieve, disseminate, and dispose of information to designated stakeholders.
Information Management
Protections for information to be managed are identified.
Information Management Outcome
Information representations are defined with consideration of security aspects.
Information Management Outcome
Information is securely obtained, developed, transformed, stored, validated, presented, and disposed.
Information Management Outcome
The security aspects of information status are identified.
Information Management Outcome
Information is available to designated stakeholders in compliance with authorized access, use, and dissemination criteria.
Information Management Outcome
Prepare for the security aspects of information management.
Information Management Activity
Perform the security aspects of information management.
Information Management Activity
Technical management process whose purpose is to collect, analyze, and report security-relevant data and information to support effective management and to demonstrate the quality of products, services, and processes.
Measurement
Security-relevant information needs are identified.
Measurement Outcome
An appropriate set of security measures, based on the security-relevant information needs, are identified or developed.
Measurement Outcome
Required security-relevant data is collected, verified, and stored.
Measurement Outcome
Security-relevant data is analyzed, and the results are interpreted.
Measurement Outcome
Security-relevant information items provide information that support decisions.
Measurement Outcome
Technical management process whose purpose is to help ensure the effective application of the organization’s Quality Management process to the project.
Quality Assurance
The security aspects of the quality assurance strategy are established.
Quality Assurance Outcome
The security aspects of the project quality assurance procedures are defined and implemented.
Quality Assurance Outcome
Criteria and methods for the security aspects of quality assurance evaluations are defined.
Quality Assurance Outcome
The evaluations of the products, services, and processes of the project are performed, consistent with security quality management policies, procedures, and requirements.
Quality Assurance Outcome
Security results of evaluations are provided to relevant stakeholders.
Quality Assurance Outcome
Security-relevant incidents are resolved.
Quality Assurance Outcome
Prioritized security-relevant problems are treated.
Quality Assurance Outcome
Prepare for security quality assurance.
Quality Assurance Activity
Perform product or service security evaluations.
Quality Assurance Activity
Perform process security evaluations.
Quality Assurance Activity
Manage quality assurance security records and reports.
Quality Assurance Activity
Treat security incidents and problems.
Quality Assurance Activity
Security considerations are addressed by the acquisition strategy.
Acquisition Outcome
A request for a supplier to provide a product or service includes security considerations.
Acquisition Outcome
Security considerations are included in the criteria for selecting a supplier.
Acquisition Outcome
An agreement that contains security considerations is established between the acquirer and the supplier.
Acquisition Outcome
A product or service that complies with the security aspects of the agreement is accepted.
Acquisition Outcome
The security obligations of the acquirer that were defined in the agreement are satisfied.
Acquisition Outcome
Prepare security requirements for acquisition.
Acquisition Activity
Participate in the selection process.
Acquisition Activity
A decision-making activity used to identify the most acceptable solution among several potential solutions.
Trade-off Study
Evaluates each proposed solution against schedule, performance, and cost in a weighted manner.
Trade-off Study
Examples include: (i) the Pugh method, (ii) Analytic Hierarchy Process, and (iii) the Kepner Tregoe method.
Trade-off Study Methods
Includes: (i) insertion of counterfeits, (ii) unauthorized production, (iii) tampering, (iv) theft, (v) insertion of malicious software and hardware, and (vi) poor manufacturing and development practices.
Supply Chain Risks
Occurs at the intersection of security, integrity, resilience, and quality.
Supply Chain Risk
SCRM pillar that is focused on ensuring that the ICT supply chain will provide required products and services under stress of failure.
Resilience
SCRM pillar that is focused on reducing vulnerabilities that may limit the intended function of a component, lead to component failure, or provide opportunities for exploitation.
Quality
SCRM pillar that provides the confidentiality, integrity, and availability of information that (A) describes the ICT supply chain or (B) traverses the ICT supply chain as well as the parties who participating in the ICT supply chain.
Security
SCRM pillar that is focused on ensuring that the ICT products or services in the ICT supply chain are genuine, unaltered, and that the ICT products and services will perform according to acquirer specifications and without additional unwanted functionality.
Integrity
Includes: (i) insertion of counterfeits, (ii) tampering, (iii) theft, and (iv) insertion of malicious software.
Adversarial Threats
Includes: (i) natural disaster, (ii) poor quality products/services, and (iii) poor practices.
Non-adversarial Threats
Includes: (i) weaknesses to the supply chain, (ii) weaknesses within entities in the supply chain, and (iii) dependencies.
External Vulnerabilities
Includes: (i) informational systems and components, and (ii) organizational policy/processes.
Internal Vulnerabilities
Probability of a threat exploiting a vulnerability.
Likelihood
Degree of harm.
Impact
