Chapter 1 Flashcards
1
Q
Set of cohesive tasks within a process.
A
Activity
2
Q
Security commensurate with the risk and the magnitude of harm resulting from the loss, misuse, or unauthorized access to or modification of information.
A
Adequate Security
3
Q
An undesirable consequence associated with a loss.
A
Adverse Consequence
4
Q
The process an organization employs to determine whether security controls are defined as system-specific, hybrid, or common.
A
Allocation
5
Q
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.).
A
Allocation
6
Q
An analytical comparison or evaluation of proposed approaches to meet an objective.
A
Analysis of Alternatives
7
Q
Can be applied to anything — from a large military acquisition decision to a decision between two products.
A
Analysis of Alternatives
8
Q
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.
A
Analysis of Alternatives
9
Q
An analytical comparison if the operational effectiveness, cost, and risks of proposed materiel solutions to gaps and shortfalls in operational capability.
A
Analysis of Alternatives
10
Q
Analyses that document the rationale for identifying/recommending a preferred solution or solutions to the identified shortfall.
A
Analysis of Alternatives
11
Q
Can be triggered by threat changes, deficiencies, obsolescence of existing systems, or advances in technology.
A
Analysis of Alternatives
12
Q
A software program hosted by an information system.
A
Application
13
Q
A set of related physical and logical representations (i.e., views) of a system or a solution.
A
Architecture
14
Q
Conveys information about system/solution elements, interconnections, relationships, and behavior at different levels of abstractions and with different scopes.
A
Architecture
15
Q
Fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and the principles of its design and evaluation.
A
Architecture (System)
16
Q
A work product used to express an architecture.
A
Architecture Description
17
Q
Conventions, principles, and practices for the description of architecture established within a specific domain of application and/or community of stakeholders.
A
Architecture Framework
18
Q
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.
A
Architecture Trade-off Analysis
19
Q
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.
A
Architecture Trade-off Analysis
20
Q
A work product expressing the architecture of a system from the perspective of specific system concerns.
A
Architecture View
21
Q
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.
A
Authenticity
22
Q
Hardware, software, and relevant documentation for an information system at a given point in time.
A
Baseline
23
Q
Formally approved version of a configuration item, regardless of media, formally designated and fixed at a specific time during the configuration item’s lifecycle.
A
Baseline
24
Q
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.
A
Baseline Configuration
25
Physical or logical perimeter of a system.
Boundary
26
A set of instructions for a computer.
Code
27
System of communication in which arbitrary groups of letters, numbers, or symbols represent units if plain text of varying length.
Code
28
A system element.
Component
29
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
30
Factors that impose restrictions and limitations on the system or actual limitations associated with the use of the system.
Constraint
31
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
32
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
33
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
34
A requirement that is implied or transformed from a higher-level requirement.
Derived Requirement
35
Cannot be assessed since they are not contained in any requirements baseline.
Derived Requirement
36
Must trace back to at least one higher level requirement.
Derived Requirement
37
Process of defining the system elements, interfaces, and other characteristics of a system of interest in accordance with the requirements and architecture.
Design
38
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
39
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
40
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
41
System that supports a system-of-interest during its lifecycle stages but does not necessarily contribute directly to its function during operation.
Enabling System
42
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
43
Context determining the setting and circumstances of all influences upon a system.
Environment (System)
44
A network not controlled by the organization.
External Network
45
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
46
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
47
Selective termination of affected, non-essential system functions when a failure occurs or is detected in the system.
Fail Soft
48
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
49
The material components of an information system.
Hardware
50
Aggregate of directives, regulations, and tules that prescribe how an organization manages, protects, and distributes information.
Information Security Policy
51
A discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information.
Information System (IS)
52
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
53
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
54
Individual assigned responsibility for conducting information system security engineering activities.
Information Systems Security Engineer (ISSE)
55
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)
56
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)
57
Includes computers, ancillary equipment, software, firmware and similar products, services (including support services), and related resources.
Information Technology (IT)
58
Guarding against improper information modification or destruction; includes ensuring information non-repudiation and authenticity.
Integrity
59
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
60
Common boundary between independent systems or modules where interactions take place.
Interface
61
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
62
A network that is typically organization-owned, yet may be organization-controlled while not being organization-owned.
Internal Network
63
Information system(s) implemented with a collection of interconnected components.
Network
64
Passive information system-related entity (e.g., devices, files, records, tables, processes, programs, domains) containing or receiving information.
Object
65
Access to this implies access to the information it contains.
Object
66
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
67
Statement that translates or expresses a need and its associated constraints and conditions.
Requirement
68
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
69
The protective measures prescribed to meet the security requirements (e.g., confidentiality, integrity, and availability) specified for an information system.
Safeguards
70
May include security features, management constraints, personnel security, and security of physical structures, areas, and devices.
Safeguards
71
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
72
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
73
The set of minimum security controls defined for a low-impact, moderate-impact, or high-impact information system.
Security Control Baseline
74
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
75
A domain that implements a security policy and is administered by a single authority.
Security Domain
76
An interdisciplinary approach and means to enable the realization of secure systems.
Security Engineering
77
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
78
A set of criteria for the provision of security services.
Security Policy
79
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
80
Description of the minimum requirements necessary for an information system to maintain an acceptable level of risk.
Security Requirements Baseline
81
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)
82
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
83
Computer programs (stored and executed by computer hardware) and associated data ( stored in hardware) that may be dynamically written or modified during execution.
Software
84
Generally an individual, process, or device causing information to flow among objects or change to the system state.
Subject
85
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
86
Often done using implants or other vulnerabilities inserted prior to installation.
Supply Chain Attacks
87
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
88
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)
89
Any organized assembly of resources and procedures united and regulated by interaction or interdependence to accomplish a set of specific functions.
System
90
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)
91
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
92
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
93
An intentional but unauthorized act resulting in the modification of a system, components of systems, its intended behavior, or data.
Tampering
94
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
95
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
96
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
97
Understanding the growing complexity of systems to more effectively analyze, manage, and address the uncertainty associated with that complexity.
Systems Security Engineer Design Challenge
98
Integrating security requirements, functions, and services into mainstream management and technical processes within the lifecycle processes of systems
Systems Security Engineer Design Challenge
99
Building trustworthy secure systems capable of protecting stakeholder assets.
Systems Security Engineer Design Challenge
100
Not meeting a specified requirement, objective, or performance measure; adversity; disruption; hazard; threat; or bad things that happen.
System Failure
101
Intentional causing of system failure.
Forced system Failure
102
Unintentional causing of system failure.
Unforced System Failure
103
Engineering the security functions that provide system security capability.
Systems Security Engineer Role
104
Engineering the security-driven constraints for all system functions.
Systems Security Engineer Role
105
Engineering and advising for the protection of data, information, technology, methods, and assets associated with the system throughout its lifecycle.
Systems Security Engineer Role
106
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
107
Engineering effort that is initiated during the concept and development stages of the system life cycle.
New Systems
108
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
109
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
110
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
111
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
112
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
113
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
114
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
115
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)
116
The engineering effort occurs across a set of constituent systems, each system with its own stakeholders, primary purpose, and planned evolution.
Systems of Systems
117
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
118
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
119
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
120
Combination of interacting elements organized to achieve one or more stated purposes.
System
121
Member of a set of elements that constitute a system.
System Element
122
System whose life cycle is under consideration in the context of this International Standard.
System-of-interest
123
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
124
System that interacts with the system-of-interest in its operational environment.
Other System
125
Focus of the engineering effort.
System-of-interest
126
Achieved only through sound, purposeful engineering informed by the specialty discipline of systems security engineering.
Adequate Security
127
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
128
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
129
The security functions of the system that exhibit security protection behavior and therefore, have functional and performance attributes.
Active Security
130
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
131
The environment for the execution and construction of all security functions (both active protection and general system functionality).
Passive Protection
132
Includes architecture, design, and the rules that govern behavior, interaction, and utilization.
Passive Protection
133
Can be achieved by defining clear security objectives and requirements.
Documenting Adequate Security
134
Often impacts performance or drives up the cost of hardware.
Security
135
Must understand the sensitivity of the data, technology, and assets that interact or are a part of the system being designed.
Systems Security Engineer
136
Must identify the sensitivity and proved recommendations to the team on how to protect the data while stored, processed, or transmitted.
Systems Security Engineer
137
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
138
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
139
Space where the SSE: (i) develops the assurance case for acceptable security and (ii) demonstrates the assurance case is satisfied.
Trustworthiness Context Space
140
Encompasses the acquisition and supply process.
Agreement Processes
141
Encompasses lifecycle model, infrastructure, portfolio, human resource, quality, and knowledge management.
Organizational Project Enabling Processes
142
Encompasses project planning, project assessment and control, decision management, risk management, configuration management, information management, measurement, and quality assurance.
Technical Management Processes
143
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
144
Includes concept, development, production, utilization, support, and retirement.
Lifecycle Stages
145
Includes agreement, organizational project-enabling, technical management, and technical processes.
System Lifecycle Processes
146
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
147
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
148
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
149
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
150
Serves to isolate functions and related data structures into well-defined logical units.
Modularity
151
Allows the relationships of well-defined logical units to be better understood, so that dependencies are clear and undesired complexity can be avoided.
Layering
152
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
153
Provide clarity and make it possible to understand the structure of a system.
Modularity and Layering
154
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
155
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
156
Often the predominant security function of secure systems.
Mediation of Access to System Resources
157
States that policy-enforcement mechanisms utilize the least common mechanisms available when satisfying stakeholder requirements.
Principle of Efficiently Mediated Access
158
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
159
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
160
Must be carefully designed to avoid performance and covert storage and timing-channel problems.
Internal Sharing
161
States that the system design should be as small and simple as possible.
Principle of Reduced Complexity
162
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
163
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
164
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
165
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
166
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
167
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
168
This principle is particularly relevant when considering systems and components which there are complex chains of trust dependencies.
Principle of Trusted Components
169
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
170
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
171
The system takes on the trust level of its least trustworthy component.
Principle of Hierarchical Trust
172
States that the degree of protection provided to a component must be commensurate with its trustworthiness.
Principle of Inverse Modification Threshold
173
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
174
States that a component need not be protected from more trustworthy components.
Principle of Hierarchical Protection
175
The most trusted component must protect itself from all other components.
Principle of Hierarchical Protection
176
States that the system should not have extraneous trusted components.
Principle of Minimized Security Elements
177
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
178
States that each component should be allocated sufficient privileges to accomplish its specific functions, but no more.
Principle of Least Privilege
179
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
180
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
181
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
182
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
183
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
184
States that systems should minimize their reliance on other systems for their own trustworthiness.
Principle of Self-reliant Trustworthiness
185
A benefit to this principle is that the isolation of a system will make it less vulnerable to attack.
Principle of Self-reliant Trustworthiness
186
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
187
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
188
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
189
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
190
The security aspects of the problem or opportunity space are deinfed
Business or Mission Analysis Outcome
191
The security aspects of the solution space are characterized.
Business or Mission Analysis Outcome
192
The concerns, constraints, limitations, and other security considerations that can affect potential solutions are defined.
Business or Mission Analysis Outcome
193
Preliminary concepts for the security aspects of system lifecycle concepts are defined.
Business or Mission Analysis Outcome
194
Alternative solution classes that take into account security objectives, considerations, concerns, limitations, and constraints, are identified.
Business or Mission Analysis Outcome
195
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
196
Any enabling systems or services needed to achieve the security aspects of business or mission analysis are available.
Business or Mission Analysis Outcome
197
Security-relevant traceability of the business or mission problems and opportunities and the preferred alternative solution classes are established.
Business or Mission Analysis Outcome
198
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
199
Business or mission analysis activity that focuses on doing research to determine which solution best meets mission objectives.
Evaluate and Select Solution Classes
200
Business or mission analysis activity that focuses on documenting the solution.
Manage the Security Aspects of Business or Mission Analysis
201
Business or mission analysis activity that focuses on doing research to identify potential solution classes.
Characterize the Security Aspects of the Solution
202
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
203
The security interest and concerns of stakeholders of the system are identified.
Stakeholder Needs and Requirements Definition Outcome
203
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
204
Stakeholder assets and assets classes are identified.
Stakeholder Needs and Requirements Definition Outcome
205
Assest susceptibility to adversity and uncertianity is determined.
Stakeholder Needs and Requirements Definition Outcome
206
Asset protection priorities and protection assurances are determined.
Stakeholder Needs and Requirements Definition Outcome
207
Stakeholder protection needs are defined and prioritized.
Stakeholder Needs and Requirements Definition Outcome
208
Security-driven and security-informed constraints on a system are identified.
Stakeholder Needs and Requirements Definition Outcome
209
Security-oriented performance measures are defined.
Stakeholder Needs and Requirements Definition Outcome
210
The security interest and concerns of stakeholders of the system are identified.
Stakeholder Needs and Requirements Outcome
211
Stakeholder protection needs are transformed into stakeholder security requirements.
Stakeholder Needs and Requirements Definition Outcome
212
Stakeholder agreement that their protection needs and expectations are adequately reflected in the security requirements is achieved.
Stakeholder Needs and Requirements Definition Outcome
213
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
214
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
215
Traceability of stakeholder security requirements, stakeholder protection needs, and asset protection data is established.
Stakeholder Needs and Requirements Definition Outcome
216
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
217
Stakeholder needs and requirements definition activity that focuses on documenting and prioritizing assets.
Define Stakeholder Protection Needs
218
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
219
Stakeholder needs and requirements definition activity that focuses on reviewing stakeholder requirements and resolving identified issues.
Analyze Stakeholder Security Requirements
220
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
221
Stakeholder security concerns are addressed by the system architecture.
Architectural Definition Outcome
222
The concept of secure function for the system at the architecture level is defined.
Architectural Definition Outcome
223
Security viewpoints, views, and models of the system architecture are developed.
Architectural Definition Outcome
224
Security context, domains, boundaries, and external interfaces of the system are defined.
Architectural Definition Outcome
225
Security concepts, properties, characteristics, functions, behavior, or constraints are allocated to architectural elements.
Architectural Definition Outcome
226
Security-relevant system elements and their interfaces are identified.
Architectural Definition Outcome
227
The security aspects of candidate system architectures are analyzed and assessed.
Architectural Definition Outcome
228
Alignment of the architecture with the system security requirements and security design characteristics is achieved.
Architectural Definition Outcome
229
Any enabling systems or services needed for the security aspects of the architectural definition are available.
Architectural Definition Outcome
230
Traceability of architecture elements to stakeholder and system security requirements is established.
Architectural Definition Outcome
231
Candidate security-related architecture metrics are identified.
Architectural Definition Outcome
232
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
233
Architecture definition activity that focuses on gathering relevant documentation and identifying key drivers that may impact the architecture.
Develop Security Viewpoints of the Architecture
234
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
235
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
236
Architecture definition activity that focuses on assessing candidate architectures and deciding on one to establish as the baseline architecture.
Select Candidate Architecture
237
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
238
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
239
Security design characteristics of each system element are defined.
Design Definition Outcome
240
System security requirements are allocated to system elements.
Design Definition Outcome
241
Design enablers necessary for the security aspects of design definition are selected or defined.
Design Definition Outcome
242
Security interfaces and security aspects of interfaces between system elements composing the system are defined or refined.
Design Definition Outcome
243
Security-driven design alternatives for system elements are assessed.
Design Definition Outcome
244
Design artifacts that include security considerations and constraints are developed.
Design Definition Outcome
245
Any enabling systems or services needed for the security aspects of design definition are available.
Design Definition Outcome
246
Traceability of security design characteristics to the architectureal entities of the system architecture is established.
Design Definition Outcome
247
Candidate security-related design metrics are identified.
Design Definition Outcome
248
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
249
Design definition activity that focuses on transforming security architecture elements into security design characteristics.
Establish Security Design Characteristics and Enablers for Each System Element
250
Design definition activity that focuses on identifying and assessing non-developmental items (NDI).
Asses the Alternatives for Obtaining Security-relevant System Elements
251
Components that already exist that can be incorporated into the design to fulfill a security function or capability (e.g., COTS).
Non-developmental Items
252
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
253
The security aspects of system analysis needs are identified.
System Analysis Outcomes
254
Assumptions and results related to the security aspects of system analysis are identified and validated.
System Analysis Outcomes
255
System security analysis results are provided for decisions.
System Analysis Outcomes
256
Any enabling systems or services needed for the security aspects of syste analysis are available.
System Analysis Outcomes
257
Traceability of system security analysis results is established.
System Analysis Outcomes
258
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
259
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
260
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.
261
System analysis activity during which a formal design review would take place.
Perform the Security Aspects of System Analysis
262
Technical process whose purpose is to realize a specified system element.
Implementation
263
The security aspects of the implementation strategy are developed.
Implementation Outcome
264
The security aspects of implementation that constrain the requirements, architecture, or design are identified.
Implementation Outcome
265
A security-relevant or security-informed system element is realized.
Implementation Outcome
266
System elemetns are securely packaged and stored.
Implementation Outcome
267
Any enabling systems or services needed for the security aspects of implementation are available.
Implementation Outcome
268
Traceability of the security aspects of the implemented system elements is established.
Implementation Outcome
269
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
270
Implementation activity that focuses on refining implementation procedures and developing training materials for users.
Perform the Security Aspects Implementation
271
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
272
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
273
The security aspects of the integration strategy are developed.
Integration Outcome
274
The security-driven integration constraints that influence requirements, architecture, design, orinterfaces and interactions are identified.
Integration Outcome
275
An approach and checkpoints for the correct secure operation of the assembled interfaces, interactions, behavior, and system functions are developed.
Integration Outcome
276
Any enabling systems or services needed to achieve the security aspects of integration are available.
Integration Outcome
277
A trustworthy secure system composed of implemented system elements is integrated.
Integration Outcome
278
The security behavior and interactions between interfaces of implemented system elements are checked.
Integration Outcome
279
The security behavior and interactions between the system and the external environment are checked.
Integration Outcome
280
The security aspects of integration results and security anomalies are identified.
Integration Outcome
281
Traceability of the security aspects of the integrated system elements is established.
Integration Outcome
282
Integration activity that focuses on developing the integration strategy and identifying any constraints resulting from integration.
Prepare for the Security Aspects of Integration
283
Integration activity that focuses on obtaining securely configured system elements and assembling them into the system.
Perform the Security Aspects of Integration
284
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
285
Technical process whose purpose is to provide objective evidence that a system or system element fulfills its specified requirements and characteristics.
Verification
286
The security aspects of the verification strategy are developed.
Verification Outcome
287
The security aspects of verification that constrain system requirements, architecture, or design are identified.
Verification Outcome
288
Any enabling systems or services needed to achieve the security aspects of verification are available.
Verification Outcome
289
The security requirements and security characteristics of the system or system element are verified.
Verification Outcome
290
Security-driven data providing information for corrective actions is reported.
Verification Outcome
291
Evidence that the realized system satisfies the system security requirements, security views of the architecture, and security design is provided.
Verification Outcome
292
The security aspects of verification results and security anomalies are identified.
Verification Outcome
293
Traceability of the security aspects of the verified system elements is established.
Verification Outcome
294
Verification activity that focuses on identifying the scope and strategy of the verification effort.
Prepare for the Security Aspects of Verification
295
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
296
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
297
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
298
Verification activity that focuses on developing and performing the test procedures for verification of the security aspects of the design.
Perform Security-focused Verification
299
Verification activity that focuses on recording the results and anomalies found during verification.
Manage Results of Security-focused Verification
300
Technical process whose purpose is to establish a capability for a system to provide services specified by stakeholder requirements in the operational environment.
Transition
301
The security aspects of the transition strategy are developed.
Transition Outcome
302
The security aspects of transition that constrain system requirements, architecture, or design are identified.
Transition Outcome
303
Any enabling systems or services needed to achieve the security aspects of transition are available.
Transition Outcome
304
The preparation of the operational site includes its security aspects.
Transition Outcome
305
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
306
Individuals involved with the operation, sustainment, and support of the system are trained in the system security capabilities and limitations.
Transition Outcome
307
Security-relevant transition results and anomalies are identified.
Transition Outcome
308
The installed system is activated and ready for operation in consideration of security-relevant capability, constraints, limitations, and identified anomalies.
Transition Outcome
309
Traceability of the security aspects of the transitioned elements is established.
Transition Outcome
310
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
311
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
312
Transition activity that focuses on recording anomalies, security aspects, operational incidents, and problems.
Manage Results of the Security Aspects of Transition
313
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
314
The security aspects of the validation strategy are developed.
Validation Outcome
315
Validation criteria for stakeholder security requirements are defined.
Validation Outcome
316
The availability of security services required by stakeholders is confirmed.
Validation Outcome
317
The security aspects of validation that constrain requirements, architecture, or design are identified.
Validation Outcome
318
The security aspects of the system or system element are validated.
Validation Outcome
319
Any enabling systems or services needed to achieve the security aspects of validation are available.
Validation Outcome
320
Security-focused validation results and security anomalies are identified.
Validation Outcome
321
Evidence that the realized system or system elements satisfies stakeholder protection needs is provided.
Validation Outcome
322
Traceability of the validated security-relevant system elements is established.
Validation Outcome
323
Validation activity that focuses on developing the scope and strategy of validation actions.
Prepare for the Security Aspects of Validation
324
Validation activity that focuses on developing and performing procedures.
Perform the Security Aspects of Validation
325
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
326
Techincal process whose purpose is to use the system to deliver its services.
Operation
327
The security aspects of the operation strategy are developed.
Operation Outcome
328
The security aspects of operation that constrain system requirements, architecture, or design are identified.
Operation Outcome
329
Any enabling systems or services needed to support the secure operation of the system are available.
Operation Outcome
330
Trained and qualified personnel capable of securely operating the system are available.
Operation Outcome
331
System services that meet stakeholder security requirements are delivered.
Operation Outcome
332
The security aspects of system performance during operation are monitored.
Operation Outcome
333
Traceability of the security aspects of operations elements is established.
Operation Outcome
334
Security support to the customer is provided.
Operation Outcome
335
Operation activity that focuses on developing the scope and strategy of operation actions.
Perpare for Secure Operation
336
Operation activity that focuses on the secure use of the system as intended in the intended environment.
Perform Secure Operation
337
Operation activity that focuses on recording the results and incidents.
Manage Results of Secure Operation
338
Operation activity that focuses on documenting customer requests for support and providing assistance to customers.
Support Security Needs of Customers
339
Technical Process whose purpose is to sustain the capability of the system to provide a service.
Maintenace
340
The security aspects of the maintenance strategy are developed.
Maintenace Outcome
341
The security aspects of maintenance and logistics that constrain system requirements, architecture, or design are identified.
Maintenace Outcome
342
Any enabling systems or services needed to support the security aspects of system maintenance and logistics are available.
Maintenace Outcome
343
Replacement, repaired, or modified system elements are available in consideration of their security aspects.
Maintenace Outcome
344
The need for changes to address security-relevant corrective, perfective, or adaptive maintenance is reported.
Maintenace Outcome
345
Security-relevant aspects, failure, and lifetime data, including associated costs, are determined.
Maintenace Outcome
346
Traceability of the security aspects of the maintained elements is established.
Maintenace Outcome
347
Maintenance activity that focuses on defining the maintenance strategy and identifying system constraints and trade spaces.
Prepare for the Security Aspects of Maintenance
348
Maintenance activity that focuses on reviewing incident and problem reports and implementing system restoration actions or preventative maintenance.
Perform the Security Aspects of Maintenance
349
Maintenance activity that focuses on acquisition and operational logistics.
Perform the Security Aspects of Logistics Support
350
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
351
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
352
The security aspects of the disposal strategy are developed.
Disposal Outcome
353
The security aspects of disposal that constrain system requirements, architecture, or design are identified.
Disposal Outcome
354
Any enabling systems or services needed to support the security aspects of disposal are available.
Disposal Outcome
355
System elements are securely removed from service, destroyed, stored, reclaimed, or recycled.
Disposal Outcome
356
The environment is returned to its original secure or agreed-upon secure state.
Disposal Outcome
357
Records of secure disposal actions and analysis are available.
Disposal Outcome
358
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
359
Disposal activity that focuses on removing impacted systems, system elements, or operating staff.
Perform the Security Aspects of Disposal
360
Disposal activity that focuses on confirming that no unresolved factors exist and restoring the environment.
Manage Results of the Security Aspects for Disposal
361
The only organizational official that can accept the security and privacy risk to organizational operations, organizational assets, and individuals.
Authorization Official
362
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
363
Is enforced individually and in combination by human, physical and automated system elements.
Security Policy
364
Rules that govern access to, operations on, and disclosure of system elements.
Confidentiality
365
Rules that govern the modification and destruction of system elements and that govern the manner in which system elements can be manipulated.
Integrity
366
Rules that govern the presence, accessibility, readiness, and continuity of service of system elements.
Availability
367
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
368
Identify the assets to be protected and scope of protection.
Security Policy Objectives
369
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
370
Specifies what a system with security policy enforcement responsibility is expected to do.
System Security Policy
371
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
372
The use of open or public designs for system security that do not rely on secret or proprietary design elements.
Open Design Concept
373
Advantages of this software design concept are low cost and customization.
Open Design Concept
374
Involves the development of software for which the organization or other licensed entity is the sole owner.
Proprietary Design Concept
375
Lifecycle model that describes each activity as a sequential top-down series of independent steps.
Waterfall/Predictive Model
376
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
377
Lifecycle model used to effectively manage disruptive technology and is focus on rapid and transparent feedback loops with the customer.
Agile/Iterative Model
378
This simple model compares the uncertainty of requirements with the technical degree of uncertainty in a project.
Uncertainty and Complexity Model
379
When tasks and activities to complete a project appear to have low uncertainty requirements in requirements definition and in technical uncertainty.
Simple Projects
380
When tasks and activities to complete a project appear to have increased uncertainty requirements in requirements definition and in technical uncertainty.
Complex Projects
381
When tasks and activities to complete a project appear to have high uncertainty requirements in requirements definition and in technical uncertainty.
Chaotic Projects
382
Lifecycle that works well on projects where the requirements and technical delivery have low uncertainty.
Waterfall/Predictive Lifecycles
383
Lifecycle that wors well on projects where the customer may not know exactly what they want for a finished product.
Iterative Lifecycles
384
Lifecycle that provides finished deliverables that the customer can both review and use immediately; focus is on speed.
Incremental Lifecycles
385
Lifecycle that is a combination of iterative and incremental lifecycle approaches; delivers highest value work first.
Agile Lifecycles
386
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
387
Agile team member that contributes to the entire set of skills necessary to produce a working product.
Cross-functional Team Member
388
Agile team member that guides product design and delivery.
Product Owner
389
Agile team member that manages the production of the working product.
Team Facailitator
390
Chart that shows number of features completed, number of features remaining, and new features added to the project.
Agile Burndown Chart
391
Easy to understand and provide a rigid clarity and clearly defined structure.
Waterfall Model Pros
392
Difficult to manage under complexity, assumes all requirements can be defined in advance, and is difficult to insert new technology.
Waterfall Model Cons
393
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
394
Needs a disciplined and experienced product owner and products may be delivered without appropriate security measures.
Agile Model Cons
395
This lifecycle has fixed requirements, activities are performed once, single products are delivered, and the goal is cost management.
Predictive Lifecycle
396
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
397
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
398
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
399
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)
400
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
401
Technical management process whose purpose is to produce and coordinate effective and workable plans.
Project Planning
402
Security objectives and the security aspects of project plans are defined.
Project Planning Outcome
403
Systems security engineering roles, responsibilities, accountabilities, and authorities are defined.
Project Planning Outcome
404
Resources and services necessary to achieve the security objectives of the project are formally requested and committed.
Project Planning Outcome
405
Plans for the execution of the security aspects of the project are activated.
Project Planning Outcome
406
Define the security aspects of the project.
Project Planning Activity
407
Plan the security aspects of the project and technical management.
Project Planning Activity
408
Activate the security aspects of the project.
Project Planning Activity
409
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
410
The security aspects of performance measures or assessment results are available.
Project Assessment and Control Outcome
411
The adequacy of security-relevant roles, responsibilities, accountabilities, and authorities is assessed.
Project Assessment and Control Outcome
412
The adequacy of resources allocated to the security aspects of the project is assessed.
Project Assessment and Control Outcome
413
The security aspects of technical progress reviews are performed.
Project Assessment and Control Outcome
414
Deviations in the security aspects of project performance from plans are investigated and analyzed.
Project Assessment and Control Outcome
415
Lessons learned are recorded to help inform and guide future projects and activities within projects.
Project Assessment and Control Outcome
416
Affected stakeholders are informed of the security aspects of project status.
Project Assessment and Control Outcome
417
Corrective action is defined and directed, when the security aspects of project achievement are not meeting targets.
Project Assessment and Control Outcome
418
The security aspects of project replanning are initiated, as necessary.
Project Assessment and Control Outcome
419
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
420
Project security objectives are achieved.
Project Assessment and Control Outcome
421
Plan for the security aspects of project assessment and control.
Project Assessment and Control Activity
422
Assess the security aspects of the project.
Project Assessment and Control Activity
423
Control the security aspects of the project.
Project Assessment and Control Activity
424
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
425
The most important systems security engineering decisions that must typically be made within the project.
Trade-space/Trade-off Decisions
426
The security aspects of the decision management strategy are established.
Decision Management Outcome
427
The security aspects of decisions requiring alternative analysis are identified.
Decision Management Outcome
428
Security-based decisions requiring alternative analysis are identified.
Decision Management Outcome
429
The security aspects of alternative courses of action are identified and evaluated.
Decision Management Outcome
430
A preferred course of action informed by or driven by security considerations is selected.
Decision Management Outcome
431
The security aspects of a resolution, of the decision rationale, and of the assumptions are identified.
Decision Management Outcome
432
Prepare for decisions with security implications.
Decision Management Activity
433
Analyze the security aspects of decision information.
Decision Management Activity
434
Make and manage security decisions.
Decision Management Activity
435
Technical management process whose purpose is to identify, analyze, treat, and monitor the risks continually.
Risk Management
436
The security aspects of the risk management strategy are defined.
Risk Management Outcome
437
Security risks are identified and analyzed.
Risk Management Outcome
438
Security risk treatment options are identified, prioritized, and selected.
Risk Management Outcome
439
Appropriate security risk treatment is implemented.
Risk Management Outcome
440
Security risks are evaluated on an ongoing basis to assess changes in status and progress in security risk treatment.
Risk Management Outcome
441
Security risks are recorded and maintained in the risk profile.
Risk Management Outcome
442
Plan security risk management.
Risk Management Activity
443
Manage the security aspects of the risk profile.
Risk Management Activity
444
Analyze security risk.
Risk Management Activity
445
Treat security risk.
Risk Management Activity
446
Monitor security risk.
Risk Management Activity
447
Technical management process whose purpose is to manage and control system elements and configurations over the life cycle.
Configuration Management
448
The security aspects of the configuration management strategy are defined.
Configuration Management Outcome
449
The security aspects of configuration items are identified and managed.
Configuration Management Outcome
450
Security criteria are included in configuration baselines
Configuration Management Outcome
451
Changes to items under configuration management are securely controlled.
Configuration Management Outcome
452
Security aspects are included in configuration status information.
Configuration Management Outcome
453
Completed configuration audits include security criteria.
Configuration Management Outcome
454
The security aspects of system releases and deliveries are controlled and approved.
Configuration Management Outcome
455
Plan for the security aspects of configuration management.
Configuration Management Activity
456
Perform the security aspects of configuration identification.
Configuration Management Activity
457
Perform security configuration change management.
Configuration Management Activity
458
Perform security configuration status accounting.
Configuration Management Activity
459
Perform security configuration evaluation.
Configuration Management Activity
460
Perform the security aspects of release control.
Configuration Management Activity
461
Technical management process whose purpose is to generate, obtain, confirm, transform, retain, retrieve, disseminate, and dispose of information to designated stakeholders.
Information Management
462
Protections for information to be managed are identified.
Information Management Outcome
463
Information representations are defined with consideration of security aspects.
Information Management Outcome
464
Information is securely obtained, developed, transformed, stored, validated, presented, and disposed.
Information Management Outcome
465
The security aspects of information status are identified.
Information Management Outcome
466
Information is available to designated stakeholders in compliance with authorized access, use, and dissemination criteria.
Information Management Outcome
467
Prepare for the security aspects of information management.
Information Management Activity
468
Perform the security aspects of information management.
Information Management Activity
469
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
470
Security-relevant information needs are identified.
Measurement Outcome
471
An appropriate set of security measures, based on the security-relevant information needs, are identified or developed.
Measurement Outcome
472
Required security-relevant data is collected, verified, and stored.
Measurement Outcome
473
Security-relevant data is analyzed, and the results are interpreted.
Measurement Outcome
474
Security-relevant information items provide information that support decisions.
Measurement Outcome
475
Technical management process whose purpose is to help ensure the effective application of the organization's Quality Management process to the project.
Quality Assurance
476
The security aspects of the quality assurance strategy are established.
Quality Assurance Outcome
477
The security aspects of the project quality assurance procedures are defined and implemented.
Quality Assurance Outcome
478
Criteria and methods for the security aspects of quality assurance evaluations are defined.
Quality Assurance Outcome
479
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
480
Security results of evaluations are provided to relevant stakeholders.
Quality Assurance Outcome
481
Security-relevant incidents are resolved.
Quality Assurance Outcome
482
Prioritized security-relevant problems are treated.
Quality Assurance Outcome
483
Prepare for security quality assurance.
Quality Assurance Activity
484
Perform product or service security evaluations.
Quality Assurance Activity
485
Perform process security evaluations.
Quality Assurance Activity
486
Manage quality assurance security records and reports.
Quality Assurance Activity
487
Treat security incidents and problems.
Quality Assurance Activity
488
Security considerations are addressed by the acquisition strategy.
Acquisition Outcome
489
A request for a supplier to provide a product or service includes security considerations.
Acquisition Outcome
490
Security considerations are included in the criteria for selecting a supplier.
Acquisition Outcome
491
An agreement that contains security considerations is established between the acquirer and the supplier.
Acquisition Outcome
492
A product or service that complies with the security aspects of the agreement is accepted.
Acquisition Outcome
493
The security obligations of the acquirer that were defined in the agreement are satisfied.
Acquisition Outcome
494
Prepare security requirements for acquisition.
Acquisition Activity
495
Participate in the selection process.
Acquisition Activity
496
A decision-making activity used to identify the most acceptable solution among several potential solutions.
Trade-off Study
497
Evaluates each proposed solution against schedule, performance, and cost in a weighted manner.
Trade-off Study
498
Examples include: (i) the Pugh method, (ii) Analytic Hierarchy Process, and (iii) the Kepner Tregoe method.
Trade-off Study Methods
499
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
500
Occurs at the intersection of security, integrity, resilience, and quality.
Supply Chain Risk
501
SCRM pillar that is focused on ensuring that the ICT supply chain will provide required products and services under stress of failure.
Resilience
502
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
503
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
504
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
505
Includes: (i) insertion of counterfeits, (ii) tampering, (iii) theft, and (iv) insertion of malicious software.
Adversarial Threats
506
Includes: (i) natural disaster, (ii) poor quality products/services, and (iii) poor practices.
Non-adversarial Threats
507
Includes: (i) weaknesses to the supply chain, (ii) weaknesses within entities in the supply chain, and (iii) dependencies.
External Vulnerabilities
508
Includes: (i) informational systems and components, and (ii) organizational policy/processes.
Internal Vulnerabilities
509
Probability of a threat exploiting a vulnerability.
Likelihood
510
Degree of harm.
Impact
