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
