- Within the systems security engineering (SSE) process described in NIST SP 800-160 Vol. 1, the primary purpose of defining the 'protection needs' early in the life cycle is to:
- Produce the system's interconnection security agreements
- Select specific COTS security products before requirements are finalized
- Document the residual risk acceptance signed by the authorizing official
- Establish a basis for deriving security requirements that protect against loss of asset value to stakeholders
Correct answer: Establish a basis for deriving security requirements that protect against loss of asset value to stakeholders
Protection needs express what stakeholders stand to lose and form the foundation from which security requirements are derived, ensuring engineering effort is grounded in stakeholder value rather than arbitrary controls.
- An ISSEP applies the concept of 'trustworthiness' to a system. Trustworthiness is best characterized as:
- The number of security controls implemented from a baseline
- A measure of how quickly the system recovers from a denial-of-service attack
- The vendor's reputation in the marketplace
- The degree to which a system can be expected to preserve the confidentiality, integrity, and availability of the information it handles
Correct answer: The degree to which a system can be expected to preserve the confidentiality, integrity, and availability of the information it handles
Trustworthiness is the demonstrated and evidence-based degree of confidence that a system performs as expected, including preserving security properties, despite environmental disruptions, errors, and attacks.
- The principle of 'loss control' in systems security engineering emphasizes that engineering should focus on:
- Transferring all risk to a third-party insurer
- Eliminating every possible vulnerability before deployment
- Maximizing the number of detective controls
- Managing asset loss consequences to acceptable levels rather than pursuing perfect prevention
Correct answer: Managing asset loss consequences to acceptable levels rather than pursuing perfect prevention
Because perfect security is unattainable, SSE focuses on controlling loss to acceptable levels through prevention, detection, and response, balancing cost and consequence.
- In the SSE framework, a 'security architecture' differs from a 'security design' primarily in that the architecture:
- Is produced only after the system is operational
- Specifies vendor part numbers and configuration settings
- Is identical to the system's network diagram
- Describes the structural relationships and allocation of security functions at a higher level of abstraction
Correct answer: Describes the structural relationships and allocation of security functions at a higher level of abstraction
Security architecture defines the structure, behavior, and allocation of security functions to components at an abstract level; design then refines that architecture into implementable detail.
- The 'reference monitor' concept requires that the validation mechanism be tamperproof, always invoked, and:
- Implemented entirely in hardware
- Small enough to be subject to analysis and testing to ensure correctness
- Distributed across all system nodes
- Capable of encrypting all data at rest
Correct answer: Small enough to be subject to analysis and testing to ensure correctness
The reference monitor must be evaluatable: small and simple enough to be completely analyzed and tested, in addition to being tamperproof and non-bypassable.
- When an ISSEP advocates 'security as an emergent property' of a system, the most accurate interpretation is that security:
- Can be measured solely by counting implemented controls
- Is only relevant during the operations phase
- Results from the interactions among system elements and cannot be fully assured by examining components in isolation
- Appears spontaneously once all controls are installed
Correct answer: Results from the interactions among system elements and cannot be fully assured by examining components in isolation
Security emerges from the integrated behavior and interactions of system elements; assessing components individually is insufficient to assure the security of the whole.
- Which statement best distinguishes 'security functions' from 'security mechanisms' in SSE?
- Functions exist only in software; mechanisms only in hardware
- Mechanisms are policy statements; functions are hardware
- Functions are what the system must do to be secure; mechanisms are the means by which functions are realized
- They are synonymous and interchangeable
Correct answer: Functions are what the system must do to be secure; mechanisms are the means by which functions are realized
A security function defines a required security capability or behavior, while a security mechanism is the specific implementation (logic, hardware, or procedure) that provides that function.
- The 'defense in depth' strategy is most correctly understood by an ISSEP as:
- Deploying multiple identical firewalls in series
- Relying on a single strong perimeter control
- Encrypting data only at the application layer
- Applying multiple, diverse, and complementary protection layers so that failure of one does not lead to total compromise
Correct answer: Applying multiple, diverse, and complementary protection layers so that failure of one does not lead to total compromise
Defense in depth uses layered, diverse, and complementary safeguards so that the compromise of one layer is mitigated by others, increasing attacker work factor and reducing single points of failure.
- In NIST SP 800-160, 'assurance' is best defined as:
- The number of penetration tests performed
- Grounds for justified confidence that a claim about the system has been or will be achieved
- A contractual warranty from the integrator
- The encryption strength of stored data
Correct answer: Grounds for justified confidence that a claim about the system has been or will be achieved
Assurance is the measure of confidence, supported by evidence, that the security functionality and properties of a system are correctly implemented and effective.
- An ISSEP is asked to apply 'least privilege' at the architectural level. The most architecturally sound application is to:
- Use a single shared service account for all processes
- Disable all logging to reduce overhead
- Partition the system so that components and subjects operate with only the rights necessary for their assigned function
- Grant administrators full rights to simplify operations
Correct answer: Partition the system so that components and subjects operate with only the rights necessary for their assigned function
Least privilege at the architecture level drives partitioning and decomposition so each element holds only the minimum authorizations required, limiting the blast radius of any compromise.
- The 'system life cycle' processes in SSE include technical and non-technical processes. Which is a primary technical process most associated with the ISSEP role?
- Human resource management
- Stakeholder needs and requirements definition
- Contract negotiation
- Payroll administration
Correct answer: Stakeholder needs and requirements definition
Stakeholder needs and requirements definition is a core technical process in ISO/IEC 15288 and NIST SP 800-160, central to engineering security into the system.
- When establishing the security 'concept of operations' (CONOPS), the ISSEP's chief objective is to:
- Describe how the system will be used and protected from the stakeholders' operational viewpoint
- Define the budget for security tooling
- List the configuration baselines for all routers
- Specify the exact cryptographic algorithms
Correct answer: Describe how the system will be used and protected from the stakeholders' operational viewpoint
A security CONOPS captures operational scenarios, missions, and protection expectations from the user's perspective, guiding subsequent requirements and design decisions.
- Which describes the relationship between 'security requirements' and 'security objectives'?
- Requirements are written after the system is decommissioned
- Objectives are testable statements; requirements are aspirational goals
- Objectives express desired security outcomes; requirements are the specific, verifiable conditions that satisfy those objectives
- They are unrelated artifacts
Correct answer: Objectives express desired security outcomes; requirements are the specific, verifiable conditions that satisfy those objectives
Security objectives state intended outcomes, while requirements translate those objectives into specific, verifiable conditions the system must meet.
- An ISSEP uses 'abstraction' as an engineering technique chiefly to:
- Manage complexity by exposing only the relevant detail at each level of design
- Increase the number of components
- Encrypt all interfaces
- Hide vulnerabilities from auditors
Correct answer: Manage complexity by exposing only the relevant detail at each level of design
Abstraction manages complexity by presenting only essential information at a given level, enabling reasoning about the system without being overwhelmed by lower-level detail.
- In the context of SSE, 'security' is fundamentally about protecting assets from:
- Only insider threats
- Only natural disasters
- Only external attackers
- Asset loss and the associated adverse consequences arising from a range of threats including hazards and human error
Correct answer: Asset loss and the associated adverse consequences arising from a range of threats including hazards and human error
SSE addresses the full spectrum of loss-causing events, including malicious attacks, accidents, environmental disruptions, and human error, not just deliberate adversaries.
- A 'protection need' that states 'the system shall preserve the integrity of patient dosage records' is best categorized as:
- A design constraint
- A test case
- A stakeholder security objective driving downstream requirements
- A specific cryptographic mechanism
Correct answer: A stakeholder security objective driving downstream requirements
This is a stakeholder-level security objective expressing a protection need; it must be decomposed into verifiable requirements and then allocated to design elements.
- The ISSEP applies 'modularity' in secure design primarily because it:
- Guarantees zero vulnerabilities
- Eliminates the need for testing
- Enables isolation of functions, limiting fault propagation and easing analysis and replacement
- Increases coupling between components
Correct answer: Enables isolation of functions, limiting fault propagation and easing analysis and replacement
Modularity supports separation of concerns, fault containment, and independent verification, which strengthen security and maintainability.
- Which best describes 'security domain separation' as a design principle?
- Using the same credentials across all domains
- Disabling access control between domains
- Placing all components on one flat network
- Maintaining distinct, bounded environments with controlled interactions to limit the scope of trust and compromise
Correct answer: Maintaining distinct, bounded environments with controlled interactions to limit the scope of trust and compromise
Domain separation establishes bounded protection environments with mediated interactions, confining trust and limiting how a compromise in one domain can affect others.
- An ISSEP differentiates 'verification' from 'validation' as follows:
- They are identical activities
- Validation is performed by auditors; verification by lawyers
- Verification happens only after deployment; validation only during design
- Verification confirms the system meets specified requirements; validation confirms the system meets stakeholder needs and intended use
Correct answer: Verification confirms the system meets specified requirements; validation confirms the system meets stakeholder needs and intended use
Verification answers 'did we build the system right' against requirements, while validation answers 'did we build the right system' against actual stakeholder needs.
- The use of 'trust' versus 'trustworthiness' in SSE is critical because:
- Trustworthiness is subjective and trust is objective
- They mean the same thing
- Neither concept applies to systems engineering
- Trust is what we place in a component; trustworthiness is the evidence-based degree to which that trust is warranted
Correct answer: Trust is what we place in a component; trustworthiness is the evidence-based degree to which that trust is warranted
Trust is a decision or reliance placed on an element; trustworthiness is the demonstrable, evidence-supported worthiness of that trust, and good engineering aligns the two.
- Under the NIST Risk Management Framework (RMF), 'categorize' (the first step) requires the ISSEP to:
- Select a baseline of security controls
- Authorize the system for operation
- Conduct continuous monitoring
- Determine the impact level for confidentiality, integrity, and availability based on information types per FIPS 199
Correct answer: Determine the impact level for confidentiality, integrity, and availability based on information types per FIPS 199
The Categorize step uses FIPS 199 and SP 800-60 to assign impact levels (low/moderate/high) for C, I, and A, which then drive control baseline selection.
- FIPS 199 establishes that the security categorization of an information system uses the:
- Sum of the three impact values
- High water mark: the highest impact value among C, I, and A
- Lowest impact value among C, I, and A
- Average impact value across C, I, and A
Correct answer: High water mark: the highest impact value among C, I, and A
FIPS 199 applies the high water mark principle, taking the highest of the confidentiality, integrity, and availability impact levels to set the overall system categorization.
- In NIST SP 800-30 risk assessments, 'likelihood of occurrence' is a function of:
- The probability that a threat event is initiated and the probability it results in adverse impact given system susceptibility
- The vendor's patch frequency
- Asset cost alone
- The number of controls implemented
Correct answer: The probability that a threat event is initiated and the probability it results in adverse impact given system susceptibility
SP 800-30 defines likelihood as a combination of the likelihood of threat initiation/occurrence and the likelihood that the event results in adverse impact, considering vulnerabilities and predisposing conditions.
- The RMF step that maps to 'determining whether the residual risk is acceptable' and issuing an ATO is:
- Implement
- Assess
- Authorize
- Monitor
Correct answer: Authorize
The Authorize step is where the authorizing official reviews the security and privacy posture, determines acceptability of residual risk, and renders the authorization decision.
- An ISSEP is tailoring a control baseline under SP 800-53B. 'Tailoring' may include all of the following EXCEPT:
- Adding compensating controls
- Ignoring the categorization results entirely
- Applying scoping considerations
- Specifying organization-defined parameters
Correct answer: Ignoring the categorization results entirely
Tailoring is a disciplined process of scoping, applying compensating controls, and setting parameters; it cannot disregard the categorization that drives baseline selection.
- Within enterprise risk management, 'risk framing' (per SP 800-39) primarily produces:
- The configuration baseline
- The system authorization decision
- The penetration test report
- The organizational risk management strategy, including risk tolerance and assumptions
Correct answer: The organizational risk management strategy, including risk tolerance and assumptions
Risk framing establishes the context: assumptions, constraints, risk tolerance, and priorities that govern how the organization assesses, responds to, and monitors risk.
- A 'predisposing condition' in SP 800-30 terminology is:
- A control that has been implemented
- A condition existing within the organization or system that affects the likelihood that threat events result in adverse impacts
- The motivation of an adversary
- A residual risk acceptance statement
Correct answer: A condition existing within the organization or system that affects the likelihood that threat events result in adverse impacts
Predisposing conditions are inherent characteristics (such as architecture or location) that increase or decrease the likelihood that a threat event causes adverse impact.
- When selecting a risk response, the four canonical options in NIST guidance are accept, avoid, mitigate, and:
- Transfer (or share)
- Authorize
- Encrypt
- Ignore
Correct answer: Transfer (or share)
The standard risk response options are accept, avoid, mitigate, and transfer/share, balancing cost, mission impact, and residual risk.
- The ISSEP distinguishes 'inherent risk' from 'residual risk' as:
- Inherent risk applies only to hardware
- Residual risk is always zero after authorization
- They are the same value
- Inherent risk is risk before controls; residual risk is risk remaining after controls are applied
Correct answer: Inherent risk is risk before controls; residual risk is risk remaining after controls are applied
Inherent risk is the level of risk absent any treatment, while residual risk is what remains after security controls and other treatments are applied.
- A POA&M (Plan of Action and Milestones) is most appropriately used to:
- Replace the system security plan
- Document and track remediation of identified control weaknesses and deficiencies over time
- Categorize the information system
- Define the system boundary
Correct answer: Document and track remediation of identified control weaknesses and deficiencies over time
The POA&M records weaknesses, planned corrective actions, resources, and milestones, supporting ongoing risk management and authorization decisions.
- Quantitative risk analysis computes the Annualized Loss Expectancy (ALE) as:
- ARO divided by SLE
- Exposure factor times threat count
- Asset value divided by exposure factor
- SLE multiplied by ARO (Single Loss Expectancy times Annualized Rate of Occurrence)
Correct answer: SLE multiplied by ARO (Single Loss Expectancy times Annualized Rate of Occurrence)
ALE equals SLE x ARO, where SLE is asset value times exposure factor and ARO is the expected frequency of the loss event per year.
- The principal advantage of qualitative risk analysis over quantitative analysis is that it:
- Is faster and more practical when reliable probability and loss data are unavailable
- Eliminates the need for stakeholder judgment
- Removes all subjectivity
- Always produces precise monetary figures
Correct answer: Is faster and more practical when reliable probability and loss data are unavailable
Qualitative analysis uses relative scales and expert judgment, making it practical when hard probability/cost data is scarce, at the cost of precision.
- In the RMF, 'continuous monitoring' (the Monitor step) supports ongoing authorization by:
- Deferring all risk decisions to vendors
- Replacing all controls annually
- Eliminating the need for assessments
- Maintaining situational awareness of security state and risk so authorization decisions remain current
Correct answer: Maintaining situational awareness of security state and risk so authorization decisions remain current
Continuous monitoring provides ongoing assessment of control effectiveness, security state, and changing risk, enabling near-real-time, ongoing authorization decisions.
- Threat modeling using an attack-tree approach is most valuable to the ISSEP because it:
- Decomposes adversary goals into the steps and conditions required, exposing where defenses are most effective
- Eliminates the need for control selection
- Replaces the system security plan
- Guarantees identification of every vulnerability
Correct answer: Decomposes adversary goals into the steps and conditions required, exposing where defenses are most effective
Attack trees systematically break an adversary's goal into sub-goals and preconditions, helping engineers prioritize and place countermeasures against the most consequential paths.
- Per SP 800-37, the system 'authorization boundary' is best defined by:
- The set of users authorized to access the system
- All components of an information system to be authorized for operation, excluding separately authorized systems to which it connects
- The physical fence around the data center
- Only the internet-facing components
Correct answer: All components of an information system to be authorized for operation, excluding separately authorized systems to which it connects
The authorization boundary establishes the scope of protection and accountability, encompassing the components under the same direct management control, while interconnected separately authorized systems are handled via agreements.
- When an ISSEP integrates 'supply chain risk management' (SCRM) into the RMF, the most appropriate early action is to:
- Identify and assess supply chain threats and incorporate SCRM requirements into acquisition and design decisions
- Outsource all SCRM to the vendor
- Wait until the system is operational to assess suppliers
- Assume all COTS products are trustworthy
Correct answer: Identify and assess supply chain threats and incorporate SCRM requirements into acquisition and design decisions
SP 800-161 and the RMF call for integrating supply chain risk considerations early, including supplier assessment and contractual/technical SCRM requirements during acquisition and design.
- A 'security control assessor' (SCA) role in the RMF is responsible for:
- Conducting a comprehensive, independent assessment of control implementation and effectiveness
- Defining the organizational risk tolerance
- Categorizing the information system
- Granting the authorization to operate
Correct answer: Conducting a comprehensive, independent assessment of control implementation and effectiveness
The SCA independently evaluates whether controls are implemented correctly, operating as intended, and producing the desired outcome, documenting findings for the authorizing official.
- The distinction between a 'threat source' and a 'threat event' in SP 800-30 is that:
- A threat event is always a natural disaster
- A threat source initiates or has the potential to cause a threat event; the event is the occurrence or attempt itself
- They are synonyms
- A threat source is always an insider
Correct answer: A threat source initiates or has the potential to cause a threat event; the event is the occurrence or attempt itself
A threat source (adversarial, accidental, structural, or environmental) is the entity or condition with potential to cause harm, while a threat event is the specific occurrence or attempted exploitation.
- An ISSEP advises that 'risk tolerance' should be set:
- By individual project engineers independently
- Only after a breach occurs
- By the vendor of the largest component
- At the organizational/enterprise level to provide consistent guidance for risk decisions across systems
Correct answer: At the organizational/enterprise level to provide consistent guidance for risk decisions across systems
Risk tolerance is an organizational determination (part of risk framing) that ensures consistent, defensible risk decisions across all systems and programs.
- In quantitative analysis, the Exposure Factor (EF) represents:
- The percentage of asset value lost when a specific threat is realized
- The total replacement cost of the asset
- The number of times per year a loss occurs
- The cost of the implemented control
Correct answer: The percentage of asset value lost when a specific threat is realized
EF is the proportion (percentage) of an asset's value that would be lost from a single realized threat; SLE = Asset Value x EF.
- During security requirements analysis, deriving requirements from threats and protection needs is preferable to copying a checklist because it:
- Guarantees compliance with every framework
- Reduces documentation effort
- Ensures requirements are traceable to actual stakeholder protection needs and the threat environment
- Avoids the need for verification
Correct answer: Ensures requirements are traceable to actual stakeholder protection needs and the threat environment
Requirements derived from protection needs and threats are traceable, justifiable, and right-sized, whereas blind checklist adoption can over- or under-protect and lacks rationale.
- When allocating security requirements to system components, the ISSEP's primary concern is to ensure that:
- Requirements are randomly distributed for resilience
- All requirements are assigned to the firewall
- Only software components receive requirements
- Each requirement is assigned to a specific element responsible for satisfying it, with traceability maintained
Correct answer: Each requirement is assigned to a specific element responsible for satisfying it, with traceability maintained
Requirements allocation maps each security requirement to the component(s) accountable for meeting it, preserving bidirectional traceability for verification and change management.
- A 'security view' within an enterprise architecture (e.g., DoDAF) is intended to:
- Document only physical security
- Define the procurement schedule
- Express security-relevant relationships, controls, and constraints across the architecture's other views
- Replace the operational view
Correct answer: Express security-relevant relationships, controls, and constraints across the architecture's other views
A security view overlays and integrates security concerns (requirements, controls, trust boundaries) across operational, systems, and technical views to ensure coherent protection.
- The ISSEP recommends 'open design' (Saltzer and Schroeder) as a design principle, meaning:
- Security should not depend on the secrecy of the design or mechanism, only on the secrecy of keys
- Source code must be public
- All interfaces must be unauthenticated
- Designs must use open-source software exclusively
Correct answer: Security should not depend on the secrecy of the design or mechanism, only on the secrecy of keys
Open design holds that security must not rely on obscurity of the mechanism; protection should remain effective even if the design is known, with secrecy confined to keys.
- Applying 'complete mediation' in a design requires that:
- Access decisions are cached indefinitely for performance
- Mediation occurs only at the network perimeter
- Every access to every protected object is checked for authorization
- Only the first access is checked
Correct answer: Every access to every protected object is checked for authorization
Complete mediation requires that every access to every object be checked against the authorization policy, preventing reliance on stale or bypassed permission decisions.
- The 'fail-safe defaults' principle dictates that, by default, the system should:
- Allow access during failures to preserve availability
- Disable logging on failure
- Deny access unless explicitly permitted
- Permit access unless explicitly denied
Correct answer: Deny access unless explicitly permitted
Fail-safe defaults mean the base condition is denial; access is granted only by explicit positive permission, so errors or omissions tend toward safety.
- In cross-domain solution (CDS) design, a 'guard' is used to:
- Manage user passwords
- Enforce policy on information flowing between security domains of differing trust or classification
- Provide power conditioning
- Encrypt data only at rest
Correct answer: Enforce policy on information flowing between security domains of differing trust or classification
A guard mediates and enforces information-flow policy (filtering, sanitization, inspection) between domains of differing trust or classification levels in a cross-domain solution.
- When designing for 'high availability' as a security objective, the ISSEP should prioritize:
- Using a single power source
- Eliminating single points of failure through redundancy, failover, and resilient architecture
- Adding more confidentiality controls
- Reducing the number of monitoring controls
Correct answer: Eliminating single points of failure through redundancy, failover, and resilient architecture
Availability-focused design removes single points of failure via redundancy, graceful degradation, and failover, ensuring the system withstands and recovers from disruptions.
- The 'economy of mechanism' principle advises designers to:
- Add redundant code paths
- Use proprietary algorithms
- Keep the design and implementation as simple and small as possible to ease analysis and reduce flaws
- Maximize the number of security features
Correct answer: Keep the design and implementation as simple and small as possible to ease analysis and reduce flaws
Economy of mechanism favors simplicity because simpler designs are easier to analyze, test, and verify, reducing the likelihood of latent security flaws.
- A 'security requirements traceability matrix' (SRTM) primarily provides:
- A linkage from each requirement through design, implementation, and test for verification
- A list of approved vendors
- The system's network topology
- The encryption key schedule
Correct answer: A linkage from each requirement through design, implementation, and test for verification
The SRTM maintains bidirectional traceability of each security requirement to its source, its design realization, and its verification evidence, ensuring nothing is dropped.
- Designing 'separation of duties' into a workflow primarily mitigates:
- Software licensing costs
- Network latency
- Power consumption
- The risk that a single individual can perpetrate and conceal fraud or error
Correct answer: The risk that a single individual can perpetrate and conceal fraud or error
Separation of duties divides critical functions among multiple parties so no single person can both commit and conceal a malicious or erroneous act.
- When an ISSEP selects cryptographic mechanisms for a design, the FIPS-compliance imperative is to:
- Avoid all standardized algorithms
- Use FIPS 140-validated modules and FIPS-approved algorithms for federal systems
- Use any algorithm the vendor recommends
- Prefer custom in-house algorithms
Correct answer: Use FIPS 140-validated modules and FIPS-approved algorithms for federal systems
Federal systems require FIPS-approved algorithms implemented in FIPS 140-validated cryptographic modules to assure correctness and acceptable assurance.
- The 'least common mechanism' principle recommends:
- Sharing as many mechanisms as possible among users
- Using one shared service for all functions
- Centralizing all data in a single store
- Minimizing mechanisms shared by multiple users to reduce unintended communication paths and risk
Correct answer: Minimizing mechanisms shared by multiple users to reduce unintended communication paths and risk
Least common mechanism minimizes shared resources/mechanisms across users or processes, reducing covert channels and the chance that a shared flaw affects many subjects.
- In requirements engineering, a well-formed security requirement should be:
- Ambiguous to allow flexibility
- Written only after design is complete
- Limited to a single sentence regardless of content
- Unambiguous, verifiable, traceable, and feasible
Correct answer: Unambiguous, verifiable, traceable, and feasible
Quality requirements are clear, testable, traceable to a need, and achievable; this enables verification and prevents scope creep or untestable mandates.
- When designing an architecture that must support multiple data sensitivity levels on shared infrastructure, the ISSEP should emphasize:
- Strong isolation, mediated information flow, and verifiable separation between sensitivity levels
- Disabling access controls between levels
- Storing all data in one unencrypted partition
- A single trust level for simplicity
Correct answer: Strong isolation, mediated information flow, and verifiable separation between sensitivity levels
Multi-level/multi-sensitivity environments require verifiable isolation and controlled, policy-enforced information flow to prevent unauthorized data movement between levels.
- An interface control document (ICD) contributes to secure design by:
- Replacing the risk assessment
- Defining the marketing strategy
- Listing employee phone numbers
- Specifying the data, protocols, and security constraints governing component interactions
Correct answer: Specifying the data, protocols, and security constraints governing component interactions
The ICD defines interface data formats, protocols, and security constraints, ensuring that interconnected components interact in a controlled, secure, and verifiable manner.
- The ISSEP applies 'psychological acceptability' (Saltzer and Schroeder) by ensuring that:
- Users receive no training
- All controls require multiple passwords
- Protection mechanisms are easy to use so users do not routinely bypass them
- Security mechanisms are hidden from users entirely
Correct answer: Protection mechanisms are easy to use so users do not routinely bypass them
Psychological acceptability holds that controls must be usable and unobtrusive enough that users apply them correctly and do not seek workarounds that weaken security.
- When trade-off analysis pits a stronger control against mission performance, the ISSEP's correct approach is to:
- Remove the control to maximize performance
- Defer entirely to the cheapest option
- Always choose the strongest control regardless of impact
- Conduct a structured trade-off analysis balancing risk reduction against mission, cost, and operational impact
Correct answer: Conduct a structured trade-off analysis balancing risk reduction against mission, cost, and operational impact
Security engineering requires disciplined trade-off analysis that weighs risk reduction against mission effectiveness, cost, schedule, and usability to reach a defensible balance.
- Designing 'security logging and monitoring' into the architecture is most effective when log generation is:
- Limited to successful events only
- Stored on the same account that generates the events
- Optional and configured only after an incident
- Built in at design time with protected, tamper-evident storage and sufficient detail to support detection and forensics
Correct answer: Built in at design time with protected, tamper-evident storage and sufficient detail to support detection and forensics
Effective audit capability must be engineered in early, capturing sufficient detail, protecting log integrity, and segregating storage to support detection, response, and forensics.
- An ISSEP designs identity and access management and chooses attribute-based access control (ABAC) over role-based (RBAC) primarily when:
- All users should have identical access
- There are only a handful of static roles
- Access decisions must consider dynamic, fine-grained context such as environment, resource, and subject attributes
- No policy exists
Correct answer: Access decisions must consider dynamic, fine-grained context such as environment, resource, and subject attributes
ABAC evaluates policies over subject, resource, action, and environmental attributes, enabling fine-grained, context-aware decisions that RBAC's static roles cannot easily express.
- In secure system implementation, 'secure configuration' should be derived from:
- Hardened baselines (e.g., DISA STIGs, CIS Benchmarks) tailored to the system's requirements
- Whatever the integrator prefers
- Vendor defaults applied as-is
- The fastest-to-deploy settings
Correct answer: Hardened baselines (e.g., DISA STIGs, CIS Benchmarks) tailored to the system's requirements
Secure configuration uses recognized hardened baselines such as STIGs or CIS Benchmarks, tailored to the system, rather than insecure vendor defaults.
- During implementation, the most reliable way to ensure delivered components match approved designs is to:
- Re-architect the system at deployment
- Skip verification to save time
- Trust the integrator's verbal confirmation
- Maintain configuration management with controlled baselines and verify builds against them
Correct answer: Maintain configuration management with controlled baselines and verify builds against them
Configuration management with controlled baselines provides the authoritative reference against which implemented components are verified, ensuring fidelity to the approved design.
- Security testing that examines an application with no knowledge of internal structure, simulating an external attacker, is termed:
- White-box testing
- Static code analysis
- Black-box testing
- Formal verification
Correct answer: Black-box testing
Black-box testing assesses the system from an external perspective without internal knowledge, emulating an outside attacker and complementing white-box techniques.
- Static application security testing (SAST) is best characterized as:
- A physical penetration test
- Running the application and observing behavior at runtime
- Analyzing source or binary code without executing it to find vulnerabilities
- A user acceptance test
Correct answer: Analyzing source or binary code without executing it to find vulnerabilities
SAST inspects source, bytecode, or binaries without execution, identifying flaws such as injection or unsafe APIs early in the life cycle.
- The primary purpose of security control assessment during V&V is to:
- Replace continuous monitoring
- Generate marketing material
- Determine whether controls are implemented correctly, operating as intended, and producing the desired outcome
- Define the authorization boundary
Correct answer: Determine whether controls are implemented correctly, operating as intended, and producing the desired outcome
Control assessment per SP 800-53A verifies that each control is correctly implemented, functioning as intended, and achieving the required security outcome.
- 'Validation' of a security solution most directly answers the question:
- Are the firewall rules ordered correctly?
- Is the code free of syntax errors?
- Does the system, in its operational context, actually meet the stakeholders' protection needs?
- Did we implement the control parameters correctly?
Correct answer: Does the system, in its operational context, actually meet the stakeholders' protection needs?
Validation confirms that the realized system satisfies actual stakeholder needs and intended operational use, beyond merely conforming to written requirements.
- When integrating COTS products, the ISSEP should reduce supply chain and assurance risk by:
- Disabling all product security features
- Evaluating product assurance evidence (e.g., Common Criteria), validating provenance, and testing in the target context
- Avoiding any documentation review
- Accepting all default trust
Correct answer: Evaluating product assurance evidence (e.g., Common Criteria), validating provenance, and testing in the target context
COTS integration requires assessing assurance evidence such as Common Criteria evaluations, verifying provenance/integrity, and testing the product within the actual operational context.
- Dynamic application security testing (DAST) differs from SAST because DAST:
- Tests the running application to find vulnerabilities observable at runtime
- Examines code without running it
- Requires source code access
- Is performed only on documentation
Correct answer: Tests the running application to find vulnerabilities observable at runtime
DAST executes the application and probes it at runtime, detecting issues like authentication flaws and runtime injection that are visible only during operation.
- A 'test readiness review' before security testing primarily confirms that:
- Test environment, data, procedures, and entry criteria are in place to conduct meaningful testing
- The system has already been authorized
- All risks have been eliminated
- The marketing plan is approved
Correct answer: Test environment, data, procedures, and entry criteria are in place to conduct meaningful testing
A test readiness review verifies that prerequisites, environment fidelity, procedures, and entry criteria are satisfied so that testing produces valid, repeatable results.
- Formal methods (e.g., formal verification) are most justified by an ISSEP for:
- Marketing collateral review
- Routine patch testing
- High-assurance components where mathematically rigorous proof of critical security properties is warranted
- Low-impact informational websites
Correct answer: High-assurance components where mathematically rigorous proof of critical security properties is warranted
Formal methods provide rigorous, mathematically grounded assurance and are cost-justified for the most critical, high-assurance security functions rather than routine systems.
- Penetration testing within V&V is most valuable when scoped to:
- Validate exploitability of vulnerabilities and the effectiveness of defenses under defined rules of engagement
- Unbounded testing with no rules of engagement
- Confirm only that the system boots
- Replace all other security assessments
Correct answer: Validate exploitability of vulnerabilities and the effectiveness of defenses under defined rules of engagement
Penetration testing, governed by clear rules of engagement, validates whether vulnerabilities are exploitable and how well layered defenses resist realistic attack, complementing other assessments.
- Regression security testing after a change is performed to:
- Document the marketing impact
- Eliminate the need for a POA&M
- Re-categorize the system
- Confirm that the change did not reintroduce or create security weaknesses or break existing controls
Correct answer: Confirm that the change did not reintroduce or create security weaknesses or break existing controls
Regression testing re-verifies that previously working security controls remain effective and that the change introduced no new vulnerabilities or broke existing protections.
- The ISSEP ensures 'independence' of the security assessor primarily to:
- Speed up authorization regardless of results
- Provide objective, credible assessment results free from conflicts of interest
- Increase the cost of assessment
- Avoid documenting findings
Correct answer: Provide objective, credible assessment results free from conflicts of interest
Assessor independence reduces bias and conflict of interest, giving the authorizing official credible, objective evidence on which to base risk decisions.
- When verification reveals a control deficiency that cannot be immediately remediated, the proper engineering action is to:
- Delete the related requirement
- Disable all logging
- Document it in a POA&M, assess residual risk, and consider compensating controls
- Ignore it and proceed to operations
Correct answer: Document it in a POA&M, assess residual risk, and consider compensating controls
Unremediated deficiencies are recorded in a POA&M with risk assessed and compensating controls considered, supporting an informed authorization decision.
- An effective approach to verifying that security requirements were correctly implemented across the life cycle is to:
- Rely solely on the developer's assertion
- Use the requirements traceability matrix to map each requirement to test cases and assessment results
- Test only the user interface
- Skip testing of inherited controls
Correct answer: Use the requirements traceability matrix to map each requirement to test cases and assessment results
The traceability matrix links requirements to design, implementation, and verification evidence, allowing confirmation that every requirement was implemented and tested.
- Fuzz testing primarily helps the ISSEP uncover:
- Policy documentation gaps
- Physical access weaknesses
- Input-handling defects such as crashes, memory corruption, or unexpected behavior from malformed inputs
- Personnel security violations
Correct answer: Input-handling defects such as crashes, memory corruption, or unexpected behavior from malformed inputs
Fuzzing feeds malformed or unexpected inputs to surface input-validation flaws, memory-safety issues, and other robustness defects that can become security vulnerabilities.
- Before deployment, a 'security acceptance test' is conducted to:
- Eliminate the need for monitoring
- Demonstrate that the delivered system satisfies its security acceptance criteria in the operational context
- Categorize the system for the first time
- Define new requirements
Correct answer: Demonstrate that the delivered system satisfies its security acceptance criteria in the operational context
Security acceptance testing validates against agreed acceptance criteria in (or representative of) the operational environment, providing a basis for stakeholder acceptance.
- When verifying inherited (common) controls, the ISSEP should:
- Re-implement them locally regardless
- Exclude them from the security plan
- Assume they are effective because they are inherited
- Confirm the providing entity's assessment evidence and ensure the controls satisfy the system's needs
Correct answer: Confirm the providing entity's assessment evidence and ensure the controls satisfy the system's needs
Inherited controls still require verification: the system owner must review the common control provider's assessment evidence and confirm the controls meet the inheriting system's requirements.
- A key indicator that a V&V program is mature is that defects are:
- Found only in production
- Never documented
- Resolved by removing requirements
- Detected as early as possible in the life cycle, where remediation cost is lowest
Correct answer: Detected as early as possible in the life cycle, where remediation cost is lowest
Mature V&V shifts defect detection left, finding issues early when correction is far cheaper and less disruptive than fixing them after deployment.
- During secure operations, the principal value of continuous monitoring is to:
- Eliminate the need for incident response
- Replace the system security plan
- Maintain ongoing awareness of vulnerabilities, threats, and control effectiveness to support timely risk decisions
- Reduce the number of controls each year
Correct answer: Maintain ongoing awareness of vulnerabilities, threats, and control effectiveness to support timely risk decisions
Continuous monitoring sustains situational awareness of security posture and changing risk, enabling timely, informed responses and ongoing authorization.
- A formal configuration/change control board (CCB) supports secure operations by:
- Allowing any engineer to change production at will
- Eliminating documentation
- Reviewing, approving, and documenting changes and assessing their security impact before implementation
- Approving only cosmetic changes
Correct answer: Reviewing, approving, and documenting changes and assessing their security impact before implementation
A CCB enforces disciplined change management by evaluating each proposed change for security impact, authorizing it, and maintaining records and baselines.
- Security impact analysis (SIA) is performed when a change is proposed to:
- Determine whether the change affects the security state and whether reassessment or reauthorization is needed
- Replace the categorization
- Avoid documenting the change
- Calculate the marketing budget
Correct answer: Determine whether the change affects the security state and whether reassessment or reauthorization is needed
SIA evaluates how a proposed change affects controls and risk, informing whether additional assessment, control updates, or reauthorization is required.
- An effective vulnerability management process in operations prioritizes remediation primarily by:
- The age of the hardware only
- Alphabetical order of the affected systems
- Risk, considering exploitability, exposure, and the impact to mission-critical assets
- Vendor preference
Correct answer: Risk, considering exploitability, exposure, and the impact to mission-critical assets
Remediation should be risk-prioritized, weighing exploitability, exposure, and mission impact, rather than treating all vulnerabilities equally.
- When a system reaches end of life, secure disposal of media containing sensitive data requires:
- Donating drives without action
- Sanitization appropriate to media type and data sensitivity (e.g., clear, purge, or destroy per NIST SP 800-88)
- Standard file deletion
- Reformatting the drive once
Correct answer: Sanitization appropriate to media type and data sensitivity (e.g., clear, purge, or destroy per NIST SP 800-88)
NIST SP 800-88 prescribes selecting clear, purge, or destroy based on media type and data confidentiality so residual data cannot be recovered.
- The most security-relevant reason to maintain accurate asset and configuration inventories in operations is that:
- It is required only for new systems
- It satisfies accounting depreciation rules
- It reduces electricity costs
- You cannot protect, patch, or monitor assets you do not know exist
Correct answer: You cannot protect, patch, or monitor assets you do not know exist
Accurate inventories underpin patching, monitoring, and incident response; unknown or unmanaged assets are blind spots that adversaries exploit.
- Incident response capability is integrated into secure operations chiefly to:
- Avoid documenting changes
- Detect, contain, eradicate, and recover from security events to limit loss and restore secure operation
- Eliminate the need for backups
- Replace continuous monitoring
Correct answer: Detect, contain, eradicate, and recover from security events to limit loss and restore secure operation
Incident response provides the structured capability to detect, contain, eradicate, recover, and learn from incidents, limiting loss and restoring trustworthy operation.
- When applying patches in a high-assurance operational environment, the ISSEP should ensure that patches are:
- Applied only by end users
- Applied directly to production without testing for speed
- Never applied to preserve stability
- Tested in a representative environment and assessed for security impact before deployment
Correct answer: Tested in a representative environment and assessed for security impact before deployment
Patches should undergo impact analysis and testing in a representative environment before production deployment to avoid introducing instability or new weaknesses.
- A 'rollback plan' as part of change management exists primarily to:
- Eliminate the need for testing
- Restore the system to a known-good secure state if a change causes failure or unacceptable risk
- Permanently revert all changes
- Document marketing decisions
Correct answer: Restore the system to a known-good secure state if a change causes failure or unacceptable risk
A rollback plan enables timely restoration to a validated, secure baseline if a change introduces failures or unacceptable risk, preserving availability and integrity.
- Continuous monitoring metrics are most useful when they are:
- Reported once at decommissioning
- Tied to security objectives and risk decisions, with thresholds that trigger defined actions
- Limited to system uptime only
- Collected but never reviewed
Correct answer: Tied to security objectives and risk decisions, with thresholds that trigger defined actions
Effective metrics are linked to security objectives and risk tolerance, with thresholds that drive concrete response actions rather than being collected for their own sake.
- When a major architectural change exceeds the original authorization, the correct governance action is to:
- Lower the categorization to avoid reassessment
- Proceed without notifying the authorizing official
- Delete the change record
- Re-engage the RMF (reassess affected controls and seek reauthorization as warranted)
Correct answer: Re-engage the RMF (reassess affected controls and seek reauthorization as warranted)
Significant changes that affect the security state require reassessment of impacted controls and, when warranted, reauthorization so the authorization remains valid.
- Before disposing of a system, the ISSEP should also ensure that:
- Only the hardware is recycled with no other action
- The system remains connected for convenience
- Documentation is destroyed first
- Interconnections and shared accounts are identified and securely terminated, and inherited-control dependencies are addressed
Correct answer: Interconnections and shared accounts are identified and securely terminated, and inherited-control dependencies are addressed
Secure disposal includes terminating interconnections and credentials, revoking access, sanitizing media, and addressing any controls or data other systems relied upon.
- Retaining records and audit logs through disposal is important because:
- They are needed for marketing analytics
- Legal, regulatory, and forensic obligations may require retention beyond the system's operational life
- Logs must always be destroyed with the system
- Retention has no security value
Correct answer: Legal, regulatory, and forensic obligations may require retention beyond the system's operational life
Retention and legal-hold requirements may compel preserving records and logs after disposal for compliance, accountability, and potential investigation.
- An operations-phase 'baseline drift' detection capability is valuable because it:
- Identifies unauthorized or unintended deviations from approved secure configurations
- Increases the attack surface
- Replaces incident response
- Eliminates the need for a CCB
Correct answer: Identifies unauthorized or unintended deviations from approved secure configurations
Detecting configuration drift surfaces unauthorized or accidental deviations from the approved hardened baseline, enabling correction before they become exploitable.
- When secure operations reveal that residual risk has increased beyond tolerance, the ISSEP should:
- Quietly lower the documented risk tolerance
- Disable monitoring to stop the alerts
- Take no action until the next triennial review
- Recommend additional treatment and escalate to the authorizing official for a risk decision
Correct answer: Recommend additional treatment and escalate to the authorizing official for a risk decision
Risk that exceeds tolerance must trigger recommended mitigations and escalation to the authorizing official, who decides whether to treat or formally accept the elevated risk.
- During disposal, the failure mode the ISSEP must most guard against is:
- Too many backups
- Excessive documentation
- Overly strict access controls
- Data remanence leading to unauthorized recovery of sensitive information from decommissioned media
Correct answer: Data remanence leading to unauthorized recovery of sensitive information from decommissioned media
Data remanence is the primary disposal risk: residual data on improperly sanitized media can be recovered, so media must be cleared, purged, or destroyed per its sensitivity.
- An emergency change that must bypass the normal CCB process should still be:
- Implemented and never recorded
- Hidden from the authorizing official
- Documented, security-impact assessed retroactively, and reviewed/ratified by the CCB as soon as possible
- Treated as a permanent exception with no review
Correct answer: Documented, security-impact assessed retroactively, and reviewed/ratified by the CCB as soon as possible
Even emergency changes require after-the-fact documentation, security impact assessment, and CCB ratification to preserve configuration integrity and accountability.
- The chief reason to integrate threat intelligence into continuous monitoring is to:
- Reduce the number of logs collected
- Eliminate the need for vulnerability scanning
- Replace configuration management
- Adapt detection and response to the evolving threat landscape and emerging adversary techniques
Correct answer: Adapt detection and response to the evolving threat landscape and emerging adversary techniques
Threat intelligence keeps monitoring and response aligned with current adversary tactics and indicators, improving detection of relevant, evolving threats.
- A 'common control provider' relationship affects operations because:
- Changes by the provider can alter the inheriting system's risk, requiring coordination and ongoing awareness
- The inheriting system never needs to monitor inherited controls
- It removes the need for a system security plan
- Inherited controls cannot fail
Correct answer: Changes by the provider can alter the inheriting system's risk, requiring coordination and ongoing awareness
Because inherited controls' effectiveness can change at the provider, the inheriting system must coordinate and maintain awareness, since provider changes can shift its residual risk.
- The ISSEP recommends that disposal procedures be planned:
- Never, since disposal is purely an IT task
- Only after the system has already been shut down
- Early in the life cycle so that media sanitization, key destruction, and data migration are addressed by design
- Only if a breach occurs
Correct answer: Early in the life cycle so that media sanitization, key destruction, and data migration are addressed by design
Planning disposal early ensures provisions for sanitization, cryptographic key destruction, data migration, and record retention are engineered in rather than improvised at end of life.
- In NIST SP 800-160, the 'security aspects of trade studies' require the ISSEP to:
- Exclude security from alternatives analysis
- Choose the lowest-cost option automatically
- Defer all decisions to procurement
- Evaluate candidate solutions against security criteria alongside cost, schedule, and performance
Correct answer: Evaluate candidate solutions against security criteria alongside cost, schedule, and performance
Security must be a first-class criterion in trade studies, evaluated alongside cost, schedule, and performance so that selected alternatives meet protection needs.
- A 'security requirement baseline' is placed under configuration control primarily to:
- Prevent any requirement from ever changing
- Speed up coding
- Eliminate the need for stakeholder input
- Ensure changes to security requirements are formally evaluated, approved, and traceable
Correct answer: Ensure changes to security requirements are formally evaluated, approved, and traceable
Baselining requirements under configuration control ensures that any change is reviewed for impact, approved, and tracked, preserving integrity and traceability of the security solution.
- When an ISSEP performs 'function allocation' between hardware, software, and human operators, a key security consideration is to:
- Allocate every security function to humans
- Avoid documenting the allocation
- Allocate functions arbitrarily
- Place security-critical functions where they can be most reliably and verifiably enforced, minimizing human error dependence
Correct answer: Place security-critical functions where they can be most reliably and verifiably enforced, minimizing human error dependence
Function allocation should assign security-critical functions to elements that can enforce them most reliably and verifiably, reducing dependence on error-prone manual processes where feasible.
- The use of a 'trusted computing base' (TCB) concept in design helps the ISSEP by:
- Concentrating security-critical enforcement into a minimized, well-analyzed set of components on which correctness depends
- Spreading security enforcement uniformly across all components
- Eliminating the need for access control
- Making all components equally trusted
Correct answer: Concentrating security-critical enforcement into a minimized, well-analyzed set of components on which correctness depends
The TCB isolates the components responsible for enforcing security policy into a minimized, rigorously analyzed set, so assurance effort can be focused where correctness is essential.
- When estimating impact for FIPS 199, a loss of integrity that could cause severe or catastrophic adverse effect on operations corresponds to an impact level of:
- Moderate
- High
- Negligible
- Low
Correct answer: High
FIPS 199 assigns High impact when the loss of a security objective could be expected to have a severe or catastrophic adverse effect on operations, assets, or individuals.
- An ISSEP integrating privacy into the RMF should recognize that privacy and security controls:
- Overlap but also have distinct objectives; privacy addresses processing of PII while security addresses protection from unauthorized activity
- Are always identical
- Are mutually exclusive
- Never interact
Correct answer: Overlap but also have distinct objectives; privacy addresses processing of PII while security addresses protection from unauthorized activity
Privacy and security have overlapping but distinct aims; SP 800-37 incorporates privacy considerations, with privacy controls addressing authorized PII processing risks beyond pure security protections.
- A program manager asks the ISSEP to summarize what systems security engineering (SSE) actually is, in one sentence. Which statement most accurately captures the discipline as framed by NIST SP 800-160 Volume 1?
- A penetration-testing methodology applied to operational systems
- A specialty engineering discipline of systems engineering that applies scientific and engineering principles to deliver trustworthy secure systems across the life cycle
- A compliance activity that selects the correct control baseline once a system is categorized
- A procurement process for acquiring evaluated security products
Correct answer: A specialty engineering discipline of systems engineering that applies scientific and engineering principles to deliver trustworthy secure systems across the life cycle
Systems security engineering is a specialty discipline of systems engineering that applies scientific, engineering, and assurance principles to build security into a system throughout its life cycle so the result is trustworthy. It is not merely compliance, testing, or procurement; those are activities that may occur within or alongside SSE but do not define it. NIST SP 800-160 Vol. 1 positions SSE as foundational engineering, not a bolt-on checklist.
- NIST SP 800-160 Volume 1 carries the subtitle that best signals its central aim. That aim is to provide a basis for:
- Engineering trustworthy secure systems
- Performing quantitative cost-benefit analysis of controls
- Managing supply chain contracts for defense programs
- Conducting federal security control assessments
Correct answer: Engineering trustworthy secure systems
NIST SP 800-160 Volume 1 is titled around engineering trustworthy secure systems, establishing principles, concepts, activities, and tasks for building security into systems. Control assessment, contracting, and cost analysis are addressed in other NIST publications such as SP 800-53A and SP 800-161, not as the core purpose of 800-160 Vol. 1.
- An ISSEP composes a system from several components with differing levels of demonstrated trustworthiness. Applying the 'hierarchical trust' design principle from NIST SP 800-160, the most defensible architecture ensures that:
- Trust decisions are deferred entirely to the operations phase
- Every component is treated as equally trustworthy to simplify analysis
- More trustworthy components do not depend on less trustworthy components for the security they must provide
- The least trustworthy component sets the security level for the entire system
Correct answer: More trustworthy components do not depend on less trustworthy components for the security they must provide
Hierarchical trust means a more trustworthy element should not have its security undermined by depending on a less trustworthy element; dependencies must flow toward greater, not lesser, trustworthiness. Treating all components as equal ignores measured differences, and letting the weakest component dictate the whole system confuses partitioning with composition. The principle lets engineers reason about trustworthiness when assembling components of varying assurance.
- The 'trusted components' design principle in NIST SP 800-160 states that a component must be trustworthy to a level that is:
- Always the maximum achievable regardless of cost
- Equal to the highest classification of any data in the enterprise
- Commensurate with the security dependencies that other elements place on it
- Determined solely by the vendor's marketing claims
Correct answer: Commensurate with the security dependencies that other elements place on it
A component must be trustworthy at least to a level commensurate with the security dependencies placed upon it; over-engineering every component to maximum trustworthiness wastes resources, and under-engineering a depended-upon component creates a weak link. This principle ties required assurance to the actual reliance other parts of the system have on the component, not to vendor claims or a blanket maximum.
- An ISSEP must explain the difference between 'trust' and a 'trust model' to a design team. A trust model is best described as:
- A structured representation of the trust relationships, dependencies, and assumptions among entities in a system
- A contractual warranty issued by a component supplier
- A list of FIPS-validated cryptographic modules
- The authorizing official's signed acceptance of residual risk
Correct answer: A structured representation of the trust relationships, dependencies, and assumptions among entities in a system
A trust model is a structured representation of how entities trust one another, capturing trust relationships, dependencies, and the assumptions on which that trust rests. It lets engineers reason about where trust is placed and whether it is warranted. A warranty, a module list, and an authorization decision are artifacts that may inform or result from trust analysis but are not themselves the model of trust relationships.
- During requirements analysis, a stakeholder asks the ISSEP to specify the 'security assurance level' for a high-consequence subsystem. In SSE terms, the assurance level chiefly governs the:
- Number of users permitted to access the subsystem
- Physical dimensions of the hardware enclosure
- Brand of operating system the subsystem must use
- Rigor and depth of the evidence required to justify confidence that security claims are met
Correct answer: Rigor and depth of the evidence required to justify confidence that security claims are met
A security assurance level determines how much rigor and how strong the evidence must be to justify confidence that the system's security claims hold; higher consequence demands deeper, more rigorous evidence. It does not set user counts, hardware size, or OS brand. Higher assurance typically requires more thorough analysis, testing, and documentation to substantiate the claimed security properties.
- An ISSEP is asked which NIST engineering document provides the detailed system life cycle processes (technical, technical management, agreement, and organizational project-enabling) that SSE activities are mapped onto. The most accurate answer is that these process groups originate in:
- FIPS 199 information categorization
- ISO/IEC/IEEE 15288, which NIST SP 800-160 Volume 1 adopts and augments with security
- The DoDAF operational viewpoint
- PCI DSS requirement 6
Correct answer: ISO/IEC/IEEE 15288, which NIST SP 800-160 Volume 1 adopts and augments with security
NIST SP 800-160 Volume 1 adopts the system life cycle process framework of ISO/IEC/IEEE 15288 and augments each process with security considerations. FIPS 199 addresses categorization, DoDAF is an architecture framework, and PCI DSS is a payment-card standard; none defines the full life cycle process model. Mapping SSE onto 15288 lets security integrate into mainstream systems engineering rather than running as a parallel effort.
- The most important reason an ISSEP integrates security activities into the existing system development life cycle (SDLC) rather than running a separate security project is that integration:
- Removes the requirement to document residual risk
- Allows security requirements and decisions to influence design while changes are still inexpensive to make
- Guarantees the system will pass every penetration test
- Eliminates the need for an authorization decision
Correct answer: Allows security requirements and decisions to influence design while changes are still inexpensive to make
Integrating security into the SDLC lets protection needs shape requirements, architecture, and design while change is still cheap, avoiding costly retrofits late in the life cycle. It does not remove authorization, guarantee test outcomes, or waive residual-risk documentation. Building security in early is far more effective and economical than bolting it on after the design has solidified.
- A defense program uses model-based systems engineering (MBSE). The principal security benefit an ISSEP gains from MBSE is the ability to:
- Eliminate the need for configuration management
- Avoid writing any security requirements
- Replace verification and validation with simulation alone
- Represent security requirements, functions, and trust relationships in a shared authoritative model that supports analysis and traceability
Correct answer: Represent security requirements, functions, and trust relationships in a shared authoritative model that supports analysis and traceability
MBSE centers engineering on a shared authoritative model, letting the ISSEP express security requirements, functions, and trust relationships in a form that supports automated analysis, consistency checking, and traceability across the design. It does not remove the need for requirements, V&V, or configuration management; rather, it strengthens their rigor. The model becomes a single source of truth for security as well as functional concerns.
- An ISSEP is documenting how security tasks align to a phased SDLC. Performing threat and protection-needs analysis during the requirements phase rather than the testing phase best reflects the SSE principle that security should be:
- Engineered in from the earliest life cycle activities and refined continuously
- Treated as an independent activity disconnected from systems engineering
- Addressed only after the architecture is frozen
- Limited to the operations and maintenance phase
Correct answer: Engineered in from the earliest life cycle activities and refined continuously
Security must be engineered in from the earliest life cycle activities and continuously refined, which is why threat and protection-needs analysis belong in requirements, not testing. Deferring it to architecture freeze, operations, or treating it as disconnected work produces gaps that are expensive to close later. Early and continuous security engineering is a core tenet of NIST SP 800-160.
- Which best states the relationship between the systems engineering process and the systems security engineering process?
- Systems security engineering is a specialty within systems engineering, sharing its life cycle processes while adding a security focus
- Systems engineering is a subset of systems security engineering
- They are competing processes that should be kept entirely separate
- Systems security engineering replaces systems engineering on classified programs
Correct answer: Systems security engineering is a specialty within systems engineering, sharing its life cycle processes while adding a security focus
Systems security engineering is a specialty discipline embedded within systems engineering; it uses the same life cycle processes but supplies the security perspective, requirements, and analyses. It neither competes with, replaces, nor subsumes systems engineering. This integration ensures security decisions are made within, not alongside, the broader engineering effort.
- An ISSEP is establishing 'configuration management' for a system under development. The fundamental purpose of configuration management in SSE is to:
- Authorize the system to operate
- Replace the system security plan with a change log
- Identify, control, and account for changes to baselines so the system's security posture stays known and approved
- Encrypt all data stored in the configuration database
Correct answer: Identify, control, and account for changes to baselines so the system's security posture stays known and approved
Configuration management identifies configuration items, establishes baselines, controls changes to them, and provides status accounting so the security-relevant state of the system remains known, approved, and auditable. It is not an encryption service, a substitute for the security plan, or an authorization step. Without it, unmanaged changes can silently erode the security posture that was originally engineered and verified.
- Why does an ISSEP insist that security-relevant components be placed under configuration management before the system is fielded?
- To transfer ownership of the components to the vendor
- To prevent any change from ever being made to those components
- To remove the need for regression testing after changes
- To ensure that changes affecting the security posture are reviewed, approved, and traceable, preserving the integrity of the verified baseline
Correct answer: To ensure that changes affecting the security posture are reviewed, approved, and traceable, preserving the integrity of the verified baseline
Configuration management subjects security-relevant changes to review, approval, and traceability so the verified security baseline is not undermined by unauthorized or unassessed modifications. It does not freeze components permanently, transfer ownership, or eliminate regression testing; in fact it triggers regression analysis when changes are proposed. The goal is a known, controlled, and defensible security state over time.
- A configuration control board (CCB) reviews a proposed change to a firewall ruleset. From an SSE perspective, the ISSEP's primary contribution to the CCB is to:
- Order replacement hardware for the firewall
- Assess the security impact of the change before it is approved or implemented
- Approve the change unilaterally without analysis
- Schedule the maintenance window for the change
Correct answer: Assess the security impact of the change before it is approved or implemented
The ISSEP's role at a configuration control board is to perform a security impact analysis so the board understands how the proposed change affects risk and the verified baseline before approval. Unilateral approval, scheduling, and procurement are not the security engineer's analytical contribution. Security impact analysis is what keeps configuration management an effective safeguard rather than a rubber stamp.
- When an ISSEP defines 'security requirements for acquisitions,' the most important objective is to:
- Delegate all security responsibility to the winning bidder
- Defer security requirements until after contract award
- Specify the lowest unit price as the deciding factor
- Express the protection needs and assurance evidence the acquired product or service must demonstrably satisfy
Correct answer: Express the protection needs and assurance evidence the acquired product or service must demonstrably satisfy
Acquisition security requirements must articulate the protection needs and the assurance evidence a supplier must demonstrate, so that what is bought actually meets the system's security objectives. Price-only selection, full delegation of security to the bidder, and post-award requirements all undermine assurance. Building security and assurance evidence into the solicitation is how SCRM and product trustworthiness begin.
- An ISSEP integrates supply chain risk management (SCRM) into a procurement. Which action most directly reduces the risk of a compromised or counterfeit component entering the system?
- Disabling all logging during component installation
- Verifying supplier provenance, integrity, and authenticity through controlled, traceable acquisition channels
- Waiting until the system is operational to evaluate suppliers
- Accepting components from any reseller offering the lowest price
Correct answer: Verifying supplier provenance, integrity, and authenticity through controlled, traceable acquisition channels
Verifying provenance, integrity, and authenticity through controlled and traceable channels is the core SCRM defense against counterfeit or tampered components. Buying on price alone from unvetted resellers maximizes supply chain risk, disabling logging hides problems, and deferring supplier evaluation to operations leaves the design exposed. SCRM, per NIST SP 800-161, must be applied during acquisition, not after.
- A program plans to buy a commercial security appliance. The ISSEP recommends reviewing the supplier's contractual deliverables for assurance evidence because:
- Contract deliverables are irrelevant to security
- Only the purchase price determines whether the product is secure
- Reviewing deliverables eliminates the need for any testing in the target environment
- Assurance evidence such as evaluation results and secure development documentation substantiates the product's trustworthiness claims
Correct answer: Assurance evidence such as evaluation results and secure development documentation substantiates the product's trustworthiness claims
Reviewing contractual deliverables for assurance evidence, such as independent evaluation results and secure development lifecycle documentation, substantiates whether a product's trustworthiness claims are credible. Deliverables are highly relevant, do not replace context-specific testing, and trustworthiness is not measured by price. Acquisition management uses these deliverables as part of SCRM to confirm the product can be trusted in the intended role.
- During procurement source selection, the ISSEP advocates evaluating offerors partly on their secure development and supply chain practices. The reasoning is that:
- Source selection should be based only on delivery speed
- Security is fully addressed after the product is delivered
- Weaknesses in a supplier's own processes can propagate into the delivered components and the fielded system
- Supplier practices have no bearing on the security of delivered products
Correct answer: Weaknesses in a supplier's own processes can propagate into the delivered components and the fielded system
A supplier's own development and supply chain weaknesses can propagate into delivered components and ultimately the fielded system, so those practices belong in source-selection criteria. Ignoring supplier processes, selecting only on speed, or assuming security can be fully retrofitted after delivery all leave the system exposed to upstream compromise. Evaluating supplier maturity is a recognized SCRM practice in security acquisition.
- An ISSEP performs 'resource analysis' for a security engineering effort and is asked to estimate component reliability. Mean Time Between Failures (MTBF) is most correctly applied to:
- Repairable components, expressing the average operational time between successive failures
- Non-repairable components only
- The maximum tolerable downtime for a business function
- The average time to detect an intrusion
Correct answer: Repairable components, expressing the average operational time between successive failures
MTBF applies to repairable components and expresses the average operating time between consecutive failures. Non-repairable components are characterized by MTTF instead, intrusion detection time is a different metric, and maximum tolerable downtime is MTD. Distinguishing these measures lets the ISSEP reason quantitatively about availability and resilience during resource and trade analysis.
- In an availability calculation for a security service, an ISSEP uses MTTF and MTTR. Which formula correctly expresses steady-state availability?
- Availability = MTTF x MTTR
- Availability = MTTR - MTTF
- Availability = MTTR / (MTTF + MTTR)
- Availability = MTTF / (MTTF + MTTR)
Correct answer: Availability = MTTF / (MTTF + MTTR)
Availability equals MTTF divided by the sum of MTTF and MTTR, meaning uptime over total time. The inverted ratio describes unavailability, and the product or difference of the two measures is not a meaningful availability figure. Engineering for higher availability therefore means increasing MTTF (reliability) or decreasing MTTR (faster recovery), both of which the ISSEP can influence through design.
- An ISSEP applies the Monte Carlo method during resource and risk analysis. The method's primary value is that it:
- Replaces the system security plan
- Uses repeated random sampling across input distributions to estimate the probability distribution of outcomes
- Eliminates the need to characterize input uncertainty
- Produces a single deterministic answer with no uncertainty
Correct answer: Uses repeated random sampling across input distributions to estimate the probability distribution of outcomes
Monte Carlo simulation runs many trials with randomly sampled inputs drawn from their distributions to estimate the distribution of possible outcomes, capturing uncertainty rather than yielding one fixed number. It depends on characterizing input uncertainty, does not eliminate it, and is unrelated to producing a security plan. This lets the ISSEP express cost, schedule, or risk results as ranges and probabilities to support better decisions.
- An ISSEP defines 'quality assurance' (QA) activities for a security engineering program. QA is best distinguished from quality control in that QA:
- Focuses on the processes used to build the system so defects are prevented rather than merely detected
- Is identical to penetration testing
- Is performed only after the system is decommissioned
- Inspects finished products to find defects
Correct answer: Focuses on the processes used to build the system so defects are prevented rather than merely detected
Quality assurance is process-focused and preventive, ensuring the engineering processes are sound so defects are avoided, whereas quality control is product-focused and inspects outputs to detect defects. QA is not a post-disposal activity nor the same as penetration testing. By improving the engineering process, QA raises confidence in the security and trustworthiness of what the process produces.
- An ISSEP establishes 'measurement' processes for a security engineering effort. The chief purpose of defining security measures and metrics is to:
- Generate documentation that is never reviewed
- Replace the need for verification and validation
- Satisfy auditors while ignoring engineering value
- Provide objective, decision-useful information about security progress, effectiveness, and risk
Correct answer: Provide objective, decision-useful information about security progress, effectiveness, and risk
Measurement processes exist to supply objective, decision-useful information about how security work is progressing, how effective controls are, and how risk is trending, so leaders can make informed engineering decisions. Measures that are never reviewed, used to dodge V&V, or collected only for audit theater add no engineering value. Good measures connect directly to decisions the program needs to make.
- An ISSEP evaluates whether to apply 'security process automation' to a repetitive control-assessment task. The strongest justification for automating it is that automation can:
- Eliminate the need to define the security requirement
- Improve consistency, repeatability, and speed of the task while reducing manual error
- Remove all human accountability for security outcomes
- Guarantee that no vulnerability will ever exist
Correct answer: Improve consistency, repeatability, and speed of the task while reducing manual error
Automating a repetitive, well-defined security task improves consistency, repeatability, and speed while cutting manual error, which is the core engineering rationale. Automation does not erase human accountability, guarantee zero vulnerabilities, or remove the need to define requirements. The ISSEP should automate where the task is stable and high-volume, retaining oversight of the results.
- An ISSEP participates in 'technical management' for a security engineering effort. Which activity is squarely a technical management process rather than a technical process?
- Stakeholder needs and requirements definition
- Architecture definition
- Configuration management of baselines and decisions
- System verification
Correct answer: Configuration management of baselines and decisions
Configuration management is a technical management process that controls baselines and decisions, whereas stakeholder needs definition, architecture definition, and verification are technical processes that produce the system itself. Distinguishing the two lets the ISSEP apply the right discipline: technical management governs how the work is controlled, while technical processes do the engineering. Both are needed for a trustworthy result.
- A program operates under multiple legal and regulatory regimes. When the ISSEP addresses 'security governance and compliance,' the correct engineering posture is to:
- Defer all compliance work until after authorization
- Treat applicable laws, regulations, and standards as constraints that shape requirements and design
- Ignore external regulation in favor of internal preference
- Implement only the controls that are cheapest
Correct answer: Treat applicable laws, regulations, and standards as constraints that shape requirements and design
Applicable laws, regulations, and standards are binding constraints that must shape the system's security requirements and design from the start. Ignoring them, optimizing only for cost, or deferring compliance until after authorization risks rework, legal exposure, and denied authorization. The ISSEP translates governance and compliance obligations into concrete, traceable engineering requirements.
- An ISSEP must clarify the difference between 'internal' and 'external' security authorities for a program. External security authorities are best characterized as those that:
- Are advisory and never binding
- Derive from outside the organization, such as statutory, regulatory, or contractual mandates the system must satisfy
- Exist only inside the development team
- Apply only to physical security
Correct answer: Derive from outside the organization, such as statutory, regulatory, or contractual mandates the system must satisfy
External security authorities originate outside the organization, including statutes, regulations, national standards, and contractual mandates the system is obligated to meet. They are typically binding, not merely advisory, and span technical as well as physical concerns. The ISSEP must reconcile external authorities with internal organizational policy when deriving security requirements.
- An ISSEP weighs 'open' versus 'proprietary' design concepts for a system component. Choosing an open design concept primarily means that:
- The system's security depends on keeping the design secret
- All source code must be released to the public
- Security does not rely on the secrecy of the design, only on the protection of keys and credentials
- No access controls are applied to interfaces
Correct answer: Security does not rely on the secrecy of the design, only on the protection of keys and credentials
An open design concept holds that security must not depend on the secrecy of the mechanism; protection should remain effective even if the design is known, with secrecy confined to keys and credentials. It does not require publishing source code or removing access controls, and it is the opposite of relying on design secrecy. Open design improves the ability to analyze and verify the security of the mechanism.
- An ISSEP references ISO/IEC 27001 alongside the NIST engineering framework when establishing 'structural security design principles.' The role ISO/IEC 27001 plays in this context is to provide:
- A management-system framework for establishing, operating, and improving information security
- Detailed source code for cryptographic libraries
- A penetration-testing tool
- The maximum tolerable downtime for the system
Correct answer: A management-system framework for establishing, operating, and improving information security
ISO/IEC 27001 provides a framework for an information security management system, covering how an organization establishes, operates, monitors, and improves information security. It is a management-system standard, not a code library, a testing tool, or a downtime threshold. The ISSEP uses it together with NIST engineering guidance to align organizational governance with technical security engineering.
- An ISSEP is asked to differentiate 'assurance methods' across software, hardware, virtual, and cloud assets. The unifying purpose of any assurance method, regardless of asset type, is to:
- Increase the marketing appeal of the product
- Generate evidence that supports justified confidence in the asset's security claims
- Guarantee perfect, defect-free systems
- Replace the need for security requirements
Correct answer: Generate evidence that supports justified confidence in the asset's security claims
Every assurance method, whether applied to software, hardware, virtual, or cloud assets, exists to generate evidence that justifies confidence in the asset's security claims. Assurance is about evidence-based confidence, not marketing, not a replacement for requirements, and not a guarantee of perfection. The specific techniques differ by asset type, but the assurance objective is constant.
- An ISSEP builds an 'assurance case' for a high-consequence system. The assurance case is best understood as:
- A structured argument, supported by evidence, that justifies confidence the system satisfies its security claims
- A physical container that protects hardware
- A list of every vendor used in the supply chain
- The annualized loss expectancy calculation
Correct answer: A structured argument, supported by evidence, that justifies confidence the system satisfies its security claims
An assurance case is a structured, reasoned argument backed by evidence that justifies confidence the system meets its stated security claims. It is not a physical enclosure, a supplier list, or a loss calculation. By linking claims to arguments to evidence, the assurance case makes the basis for trustworthiness explicit and reviewable, which is central to high-assurance engineering.
- An executive challenges the ISSEP: 'If we implement every control in the catalog, isn't the system automatically trustworthy?' The best engineering response is that trustworthiness:
- Is guaranteed by purchasing certified products
- Requires evidence that the realized system actually achieves its security claims, not merely that controls are present
- Cannot be assessed until a breach occurs
- Is simply the count of controls implemented
Correct answer: Requires evidence that the realized system actually achieves its security claims, not merely that controls are present
Trustworthiness is an evidence-based judgment that the realized system actually achieves its security claims; counting implemented controls does not establish that they work together correctly in context. Certified products and breach history are not substitutes for an evidence-supported argument. The ISSEP must produce assurance evidence demonstrating the system behaves as intended despite errors, faults, and attacks.
- An ISSEP explains why 'security assurance levels' are tied to consequence of loss. Setting a higher assurance level for a subsystem that handles life-safety functions is justified because:
- Higher consequence warrants stronger evidence and greater rigor to justify confidence in protection
- Assurance level is unrelated to the value of what is being protected
- Life-safety functions need no special engineering attention
- Higher assurance always costs less than lower assurance
Correct answer: Higher consequence warrants stronger evidence and greater rigor to justify confidence in protection
Assurance levels scale with consequence: the greater the potential loss, the stronger and more rigorous the evidence required to justify confidence in the protection. Higher assurance generally costs more, not less, and is very much tied to the value of the protected asset. Life-safety functions, having severe consequences of failure, justify the additional engineering rigor that a higher assurance level demands.
- An ISSEP describes the 'system life cycle' to a new team member, emphasizing that security engineering spans it. Which ordering reflects a typical life cycle progression that SSE activities follow?
- Operation, concept, disposal, production
- Concept, development, production, utilization/support, retirement
- Production, concept, retirement, development
- Disposal, operation, development, concept
Correct answer: Concept, development, production, utilization/support, retirement
A typical system life cycle progresses from concept through development, production, utilization and support, and finally retirement, and SSE activities accompany each stage. The other orderings scramble the natural sequence. Recognizing the correct progression helps the ISSEP place security tasks, such as protection-needs analysis early and sanitization planning before retirement, at the right points.
- An ISSEP is asked to identify when in the life cycle disposal and sanitization requirements should first be considered. The SSE answer is that they should be addressed:
- Never, since disposal is purely an operational concern
- Early in the life cycle so that secure disposal provisions are engineered into the design
- Only after a data breach is discovered
- Only at the moment the system is retired
Correct answer: Early in the life cycle so that secure disposal provisions are engineered into the design
Disposal and sanitization needs should be considered early so the design includes provisions such as key destruction, media sanitization, and data migration paths, rather than improvising them at retirement. Waiting until retirement, ignoring disposal, or reacting only to a breach leaves residual data and trust exposed. Engineering disposal in advance is part of treating the whole life cycle as the ISSEP's responsibility.
- An ISSEP applies the principle of 'continuous protection' from NIST SP 800-160. The principle requires that:
- Continuous monitoring replaces all protective controls
- Security-relevant components and information are protected continuously, without exploitable gaps, including during state transitions
- Protection is suspended during maintenance windows
- Protection is applied only during business hours
Correct answer: Security-relevant components and information are protected continuously, without exploitable gaps, including during state transitions
Continuous protection requires that security-relevant components and information remain protected at all times, with no exploitable gaps, including during start-up, shutdown, recovery, and other state transitions. Limiting protection to business hours, suspending it during maintenance, or conflating it with monitoring leaves windows of exposure. State transitions are a classic moment of weakness this principle is meant to close.
- An ISSEP applies 'minimized sharing' (least common mechanism) as a structural design principle. The security rationale is that shared mechanisms:
- Are required by every security standard
- Can create unintended communication paths and propagate a single flaw to many subjects
- Always improve performance with no security cost
- Eliminate the need for access control
Correct answer: Can create unintended communication paths and propagate a single flaw to many subjects
Mechanisms shared across multiple subjects can create unintended communication paths, including covert channels, and allow a single flaw to affect everyone who relies on the shared mechanism. Sharing is not cost-free from a security standpoint, is not universally mandated, and does not remove the need for access control. Minimizing sharing limits the blast radius of a compromised mechanism.
- An ISSEP applies the 'self-reliant trustworthiness' principle so that a system does not depend on external entities for its security to the extent practical. The main benefit is that the system:
- Can ignore its operational environment entirely
- No longer needs any security requirements
- Becomes immune to all attacks
- Reduces its exposure to compromise or failure of external dependencies it cannot control
Correct answer: Reduces its exposure to compromise or failure of external dependencies it cannot control
Self-reliant trustworthiness reduces a system's exposure to the compromise or failure of external entities it cannot directly control by minimizing security dependencies on them. It does not make the system immune to attack, remove the need for requirements, or let it ignore its environment. Reducing uncontrolled external dependencies is a way to bound and reason about a system's own trustworthiness.
- A program lead asks the ISSEP to distinguish 'verification of security requirements' performed throughout the process from a one-time final test. Performing requirements verification continuously throughout development is preferable because it:
- Removes the need for a final acceptance activity
- Catches deviations from security requirements early, when correction is least costly
- Defers all defect discovery to the end of the project
- Applies only to inherited controls
Correct answer: Catches deviations from security requirements early, when correction is least costly
Verifying security requirements continuously throughout development catches deviations early, when they are cheapest to correct, instead of discovering them all at a costly end-of-project gate. Continuous verification complements, rather than replaces, final acceptance, and it applies to all requirements, not only inherited controls. Early, ongoing verification is a hallmark of disciplined SSE integration with the SDLC.
- An ISSEP must explain how SSE addresses 'loss' broadly. Within NIST SP 800-160, the asset loss the engineering aims to control includes loss caused by:
- Adversarial action, human error, structural failures, and environmental disruptions
- Only deliberate adversarial attacks
- Only natural disasters
- Only configuration mistakes
Correct answer: Adversarial action, human error, structural failures, and environmental disruptions
SSE controls loss arising from the full range of causes, including adversarial action, human error, structural or component failures, and environmental disruptions, not just deliberate attacks. Narrowing the scope to only attacks, only disasters, or only configuration errors would leave significant loss sources unmanaged. Treating loss comprehensively is what lets the discipline deliver dependable protection of asset value.
- An ISSEP is asked which engineering concept ensures that a security mechanism remains effective even when an individual element it relies on fails. The applicable structural design principle is:
- Granting all subjects maximum privilege
- Eliminating logging to reduce complexity
- Redundancy combined with diversity to avoid common-mode failure of protections
- Maximizing the secrecy of the design
Correct answer: Redundancy combined with diversity to avoid common-mode failure of protections
Redundancy combined with diversity keeps protection effective when a single element fails, and diversity specifically guards against a common-mode failure that would defeat identical redundant elements at once. Relying on design secrecy, maximizing privilege, or removing logging weakens rather than strengthens protection. Diverse redundancy is how the ISSEP avoids a single fault cascading into total loss of a security function.
- An ISSEP needs to ensure that security decisions made during architecture are not lost as the design evolves. The most effective technical-management practice to preserve this is to:
- Record security decisions and their rationale and place them under configuration control with traceability
- Delete decision records once the design is approved
- Defer documenting decisions until after deployment
- Rely on the memory of individual engineers
Correct answer: Record security decisions and their rationale and place them under configuration control with traceability
Recording security decisions with their rationale and placing them under configuration control with traceability preserves the engineering intent as the design evolves and changes are proposed. Depending on memory, deleting records, or deferring documentation all invite drift away from the verified security baseline. Decision traceability lets later reviewers understand why protections exist and assess the impact of proposed changes.
- An ISSEP explains the difference between 'reliability' and 'security' to stakeholders who think they are the same. The most accurate distinction is that:
- Reliability and security are identical and interchangeable
- Reliability addresses correct function under expected conditions, while security adds the requirement to perform correctly despite intentional adversarial actions
- Security ignores accidental failures entirely
- Reliability is concerned only with adversaries
Correct answer: Reliability addresses correct function under expected conditions, while security adds the requirement to perform correctly despite intentional adversarial actions
Reliability concerns whether a system functions correctly under expected conditions, while security additionally requires correct, protected behavior even in the presence of intentional adversarial action. The two overlap but are not identical; security does not ignore accidental failures, and reliability is not focused on adversaries. The ISSEP engineers for both, since trustworthiness depends on dependable behavior under both normal stress and active attack.
- An ISSEP integrates a security-relevant change request into the technical management workflow. The single most important reason to require regression security testing as part of processing the change is to:
- Re-categorize the system at a higher impact level
- Confirm the change did not break previously verified security functions or introduce new weaknesses
- Transfer responsibility for the change to the supplier
- Demonstrate that the change request was submitted on the correct form
Correct answer: Confirm the change did not break previously verified security functions or introduce new weaknesses
Regression security testing within change processing confirms that a change has not broken previously verified security functions or introduced new weaknesses, preserving the integrity of the verified baseline. Form compliance, re-categorization, and responsibility transfer are not the purpose. Tying regression testing to configuration management is how the ISSEP keeps the security posture trustworthy as the system evolves.
- An ISSEP must select the correct reliability measure for a non-repairable sensor whose failure ends its service life. The appropriate metric is:
- Maximum Tolerable Downtime (MTD)
- Mean Time To Repair (MTTR)
- Mean Time To Failure (MTTF)
- Mean Time Between Failures (MTBF)
Correct answer: Mean Time To Failure (MTTF)
Mean Time To Failure (MTTF) is the right measure for a non-repairable item, expressing the average operating time until it fails and is replaced rather than repaired. MTBF applies to repairable items, MTTR measures recovery time, and MTD is the downtime a business function can tolerate. Choosing the correct reliability metric lets the ISSEP reason accurately about availability and resilience during resource analysis.
- A vendor argues that keeping its cryptographic algorithm secret makes the product more secure, and asks the ISSEP to endorse this proprietary design concept. Drawing on the open design principle and Kerckhoffs's principle, how should the ISSEP respond?
- Caution that security should not depend on the secrecy of the design or mechanism; only a small set of items such as keys should be secret, and the design should remain secure even if fully disclosed
- Endorse it, because secrecy of the algorithm is the strongest available protection
- Require that all source code and keys be published together so nothing is hidden
- Recommend the proprietary approach only when the system is connected to the internet
Correct answer: Caution that security should not depend on the secrecy of the design or mechanism; only a small set of items such as keys should be secret, and the design should remain secure even if fully disclosed
The open design principle, reflecting Kerckhoffs's principle, holds that a system's security must not rely on the secrecy of its design or implementation; protection should rest on sound, openly reviewable mechanisms with only a small, well-protected set of secrets such as cryptographic keys. A design that stays secure even when fully disclosed is preferable to security by obscurity. Publishing the keys themselves would defeat protection, so open design does not mean disclosing secrets, only that secrecy of the design is not the basis of security.
- An ISSEP supporting a federal program is mapping the governance and compliance landscape that constrains how the system is engineered. Which set best represents the laws, regulations, and standards an ISSEP must account for in this foundational analysis?
- Statutes such as FISMA, agency policy and directives, and standards such as the FIPS and NIST SP series that establish mandatory requirements and oversight
- Only the organization's internal coding style guide
- Only the vendor's end-user license agreement
- Only the marketing department's brand guidelines
Correct answer: Statutes such as FISMA, agency policy and directives, and standards such as the FIPS and NIST SP series that establish mandatory requirements and oversight
Security governance and compliance for a federal system are shaped by statutory authorities such as FISMA, by agency policies and directives, and by mandatory standards and guidance like the FIPS publications and NIST Special Publication series, which together set requirements and oversight the engineering effort must satisfy. A coding style guide, an EULA, or brand guidelines do not establish the legal and regulatory obligations that govern security engineering. Identifying these authorities early ensures requirements trace to genuine compliance drivers.
- An ISSEP is documenting the organizational security authorities that influence a new system and must separate internal authorities from external ones. Which pairing correctly classifies them?
- Internal: foreign adversaries; external: the program's own engineers
- Internal: the hardware vendor's sales team; external: the organization's own risk executive
- Internal: the system's authorizing official and CISO; external: oversight bodies, regulators, and standards organizations that impose requirements from outside the organization
- Internal and external authorities are identical and need not be distinguished
Correct answer: Internal: the system's authorizing official and CISO; external: oversight bodies, regulators, and standards organizations that impose requirements from outside the organization
Internal security authorities are roles within the organization that direct and accept risk for the system, such as the authorizing official, the risk executive, and the CISO, while external authorities are bodies outside the organization, such as regulators, oversight and accreditation bodies, and standards organizations, that impose requirements on it. Distinguishing the two clarifies who sets constraints versus who makes internal risk decisions. Adversaries and a vendor's sales team are not security authorities in this governance sense.
- In a DoD/IC acquisition, an ISSEP must provide the program with justified confidence that a critical security function works as intended before the authorizing official decides. Which combination of activities most directly builds the security assurance case for that function?
- Collecting vendor brochures and the unit price history of the component
- Counting the total number of users the system will support
- Confirming the system was delivered on schedule and under budget
- Accumulating evidence from requirements traceability, design analysis, testing results, and the developer's security processes, organized into an assurance case for the claim
Correct answer: Accumulating evidence from requirements traceability, design analysis, testing results, and the developer's security processes, organized into an assurance case for the claim
A security assurance case is built by accumulating and organizing evidence, traceability from requirements through design, analysis, testing results, and evidence of disciplined developer processes, to justify confidence that a specific security claim is met. This evidence-based case is what informs the authorizing official's risk decision in a DoD or IC acquisition. Brochures, price history, user counts, and schedule performance say nothing about whether the security function is correct and effective.
- During a functional configuration audit and a physical configuration audit near the end of development, an ISSEP must explain what each audit confirms. Which statement correctly distinguishes them?
- Both audits confirm only that the documentation page count is correct
- A functional configuration audit verifies the item performs as specified in its requirements, while a physical configuration audit verifies the as-built item matches its approved configuration documentation
- Neither audit relates to configuration management
- A functional configuration audit checks physical labels, while a physical configuration audit runs the test cases
Correct answer: A functional configuration audit verifies the item performs as specified in its requirements, while a physical configuration audit verifies the as-built item matches its approved configuration documentation
A functional configuration audit confirms that a configuration item actually achieves the performance and functional characteristics specified in its requirements, whereas a physical configuration audit confirms that the as-built item conforms to its approved technical and configuration documentation. Together they close out a baseline by validating both behavior and build accuracy. They are core configuration management activities, not documentation page counts or label checks.
- An ISSEP is establishing the security assurance approach for a system with components of widely differing criticality and wants effort allocated sensibly. Which strategy best reflects how security assurance levels should be applied across the system?
- Apply assurance only to components that already failed a test
- Apply the single highest assurance rigor uniformly to every component to be safe
- Apply assurance rigor proportionally, demanding the strongest evidence for the most critical security functions and trust-bearing components and less for low-consequence elements
- Apply assurance based on which components were cheapest to acquire
Correct answer: Apply assurance rigor proportionally, demanding the strongest evidence for the most critical security functions and trust-bearing components and less for low-consequence elements
Security assurance levels are applied in proportion to criticality and the consequences of failure, so the most critical security functions and the components that other elements depend on for trust receive the most rigorous analysis, testing, and evidence, while low-consequence elements need less. Applying maximum rigor everywhere wastes scarce engineering effort, and tying assurance to test failures or acquisition cost ignores where loss would actually be greatest. This risk-proportional allocation is central to engineering trustworthy secure systems.
- An ISSEP is explaining the NIST Risk Management Framework to a new program team. Which statement most accurately answers 'what is the risk management framework' as defined in NIST SP 800-37?
- A checklist of mandatory firewall and encryption settings for federal systems
- A one-time accreditation event performed just before a system goes live
- A disciplined, structured, and repeatable process for managing security and privacy risk that integrates risk management activities into the system development life cycle
- A contractual document that transfers all residual risk to the system integrator
Correct answer: A disciplined, structured, and repeatable process for managing security and privacy risk that integrates risk management activities into the system development life cycle
The Risk Management Framework is a disciplined, structured, and repeatable process for managing security and privacy risk that is integrated into the system development life cycle. It is not a static configuration checklist or a single accreditation event; SP 800-37 emphasizes ongoing, life-cycle-integrated risk management rather than a point-in-time approval.
- Under NIST SP 800-37 Revision 2, which step was added ahead of Categorize to establish the organizational and system context, roles, and risk strategy before any system is categorized?
Correct answer: Prepare
Prepare is the step added in SP 800-37 Revision 2 ahead of Categorize. It establishes context and priorities, assigns roles such as the authorizing official and system owner, defines the organizational risk management strategy and risk tolerance, and lays the groundwork that makes the remaining RMF steps more effective.
- An ISSEP lists the RMF steps for a checklist. Which ordering correctly states the six post-Prepare steps of the Risk Management Framework?
- Categorize, Implement, Select, Authorize, Assess, Monitor
- Identify, Protect, Detect, Respond, Recover, Monitor
- Categorize, Select, Implement, Assess, Authorize, Monitor
- Frame, Assess, Respond, Monitor, Authorize, Categorize
Correct answer: Categorize, Select, Implement, Assess, Authorize, Monitor
After Prepare, the RMF six steps are Categorize, Select, Implement, Assess, Authorize, and Monitor. Identify/Protect/Detect/Respond/Recover are the Functions of the NIST Cybersecurity Framework, not the RMF steps, and Frame/Assess/Respond/Monitor are the SP 800-39 risk management process components.
- A senior leader asks the ISSEP to distinguish the organization's 'risk appetite' from its 'risk tolerance.' Which description is correct per NIST guidance?
- Risk appetite is set per system by engineers, while risk tolerance is set by external auditors
- Risk appetite is the measurable threshold for a single control, while risk tolerance is the enterprise mission statement
- Risk appetite and risk tolerance are interchangeable terms for the same quantitative limit
- Risk appetite is the broad amount of risk leadership is willing to accept in pursuit of the mission, while risk tolerance is the narrower, often measurable acceptable variation around specific objectives
Correct answer: Risk appetite is the broad amount of risk leadership is willing to accept in pursuit of the mission, while risk tolerance is the narrower, often measurable acceptable variation around specific objectives
Risk appetite is the broad-based amount of risk an organization is willing to accept in pursuit of its mission, set by senior leadership, while risk tolerance is the narrower, often measurable acceptable level of variation around specific objectives. They are related but distinct: appetite is the strategic guidepost and tolerance translates it into operational, frequently quantifiable targets.
- When briefing executives, the ISSEP describes 'enterprise risk management' (ERM). Which statement best captures the purpose of ERM as it relates to cybersecurity risk?
- It focuses exclusively on insurance and the financial transfer of cyber risk
- It aggregates and normalizes risks from across the organization so cybersecurity risk can be considered alongside financial, operational, and strategic risk in enterprise-level decisions
- It confines all risk decisions to the IT department to keep them technical
- It replaces system-level RMF activities with a single annual enterprise audit
Correct answer: It aggregates and normalizes risks from across the organization so cybersecurity risk can be considered alongside financial, operational, and strategic risk in enterprise-level decisions
Enterprise risk management aggregates and normalizes risks from across the organization so cybersecurity risk can be weighed alongside financial, operational, and strategic risks at the enterprise level. NIST IR 8286 emphasizes integrating cybersecurity risk into ERM rather than treating it as an isolated IT concern or merely an insurance question.
- An ISSEP uses a cybersecurity risk register to support enterprise risk management. The primary function of the risk register is to:
- Store the cryptographic keys used by the system
- List all approved hardware and software vendors
- Serve as the authoritative network diagram for the authorization boundary
- Record identified risks with their context, likelihood, impact, response, and ownership so they can be tracked and rolled up to enterprise leadership
Correct answer: Record identified risks with their context, likelihood, impact, response, and ownership so they can be tracked and rolled up to enterprise leadership
A cybersecurity risk register records identified risks along with their context, likelihood, impact, planned response, and ownership so they can be tracked over time and aggregated into the enterprise view. Per NIST IR 8286, the register is the communication vehicle that lets cybersecurity risk inform enterprise-level decisions, not a key store or asset inventory.
- During early design, an ISSEP performs 'threat modeling' on a new data-processing system. What is the central goal of threat modeling in this context?
- To enumerate every software license required by the system
- To systematically identify potential threats, attack vectors, and the assets they target so that protections can be prioritized before flaws are built in
- To calculate the annualized loss expectancy for budgeting purposes only
- To produce the final authorization-to-operate decision memo
Correct answer: To systematically identify potential threats, attack vectors, and the assets they target so that protections can be prioritized before flaws are built in
Threat modeling systematically identifies potential threats, attack vectors, and the assets they target so that protections can be prioritized and designed in before flaws are built into the system. It is an analysis technique performed early to inform requirements and design, not a budgeting calculation or the authorization decision itself.
- An ISSEP applies the STRIDE methodology during threat modeling. STRIDE is used to:
- Score vulnerabilities using a numeric base, temporal, and environmental metric
- Rank assets by replacement cost from smallest to largest
- Define the six steps of the Risk Management Framework
- Categorize threats by spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege
Correct answer: Categorize threats by spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege
STRIDE categorizes threats into spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege, mapping each category to the security property it violates. It is a threat-classification aid for modeling, not the RMF steps and not a vulnerability scoring system like CVSS.
- After applying all selected and inherited controls, an authorizing official must understand the 'residual risk' before deciding. Residual risk is best defined as:
- Risk that has been completely transferred to a third party
- The total risk present before any controls are implemented
- The maximum risk the organization could ever face under worst-case conditions
- The portion of risk that remains after security controls and other risk responses have been applied
Correct answer: The portion of risk that remains after security controls and other risk responses have been applied
Residual risk is the portion of risk remaining after security controls and other risk responses have been applied. It is what the authorizing official weighs against the organization's risk tolerance when deciding whether to authorize the system; risk before any controls is inherent risk, and fully transferred risk is a different response category.
- An ISSEP must answer how residual risk relates to the authorization decision. Which statement is most accurate?
- The authorizing official accepts the residual risk on behalf of the organization when granting authorization to operate, based on whether it falls within risk tolerance
- Residual risk is the assessor's responsibility to accept, not the authorizing official's
- Residual risk is documented only after the system is decommissioned
- Residual risk must always be driven to zero before any authorization can be granted
Correct answer: The authorizing official accepts the residual risk on behalf of the organization when granting authorization to operate, based on whether it falls within risk tolerance
The authorizing official accepts the residual risk on behalf of the organization when granting authorization to operate, judging whether it falls within the organization's risk tolerance. Residual risk is rarely zero; the engineering goal is to reduce it to an acceptable, explicitly accepted level, and that acceptance is an authorizing-official function.
- A control assessment identifies several weaknesses that cannot be fixed before authorization. The ISSEP records them in a 'plan of action and milestones' (POA&M). The POA&M primarily documents:
- The complete inventory of authorized users and their roles
- The high water mark categorization for confidentiality, integrity, and availability
- Identified weaknesses, the corrective actions planned, the resources required, and the scheduled completion milestones
- The cryptographic algorithms approved for the system
Correct answer: Identified weaknesses, the corrective actions planned, the resources required, and the scheduled completion milestones
A plan of action and milestones documents identified weaknesses, the planned corrective actions, the resources required, and the scheduled completion milestones for remediation. It is a living management tool that lets the authorizing official make an informed risk decision and track deficiencies to closure, not an algorithm list or user inventory.
- An auditor asks the ISSEP what 'POAM' stands for and how it is used in ongoing risk management. The best answer is that a POA&M is:
- A Privacy of Authorized Materials notice for handling classified data
- A Policy on Asset Management that governs hardware procurement
- A Process for Access Management defining account provisioning
- A Plan of Action and Milestones used to track and prioritize the remediation of known security weaknesses over time
Correct answer: A Plan of Action and Milestones used to track and prioritize the remediation of known security weaknesses over time
POA&M stands for Plan of Action and Milestones, used to track and prioritize the remediation of known security weaknesses over time. It supports continuous monitoring and ongoing authorization by giving leadership visibility into open deficiencies and their planned closure dates, and it is updated as weaknesses are remediated or new ones are found.
- An ISSEP is selecting a 'risk assessment methodology' for a federal program. Which guidance document specifically provides the process and tasks for conducting information security risk assessments?
- FIPS 199
- NIST SP 800-30
- NIST SP 800-18
- NIST SP 800-53A
Correct answer: NIST SP 800-30
NIST SP 800-30 provides the process and tasks for conducting information security risk assessments, including identifying threat sources and events, vulnerabilities, likelihood, and impact. FIPS 199 covers categorization, SP 800-53A covers control assessment procedures, and SP 800-18 covers system security plan development.
- Following NIST SP 800-30, the ISSEP determines the overall level of risk for a threat event by combining:
- The likelihood that the threat event occurs and results in adverse impact, with the magnitude of that impact
- The asset purchase price and the number of users
- The vendor's market share and support contract length
- The number of controls implemented and the patch cadence
Correct answer: The likelihood that the threat event occurs and results in adverse impact, with the magnitude of that impact
Under SP 800-30, the level of risk is a function of the likelihood that a threat event occurs and results in adverse impact combined with the magnitude of that impact. This likelihood-and-impact pairing is the core of the methodology; asset price, control counts, and vendor attributes are inputs to those factors at most, not the determinants of risk by themselves.
- An ISSEP estimates risk by rating how probable an event is and how severe its consequences would be. This 'likelihood and impact' pairing is used to:
- Set the system's authorization boundary
- Prioritize risks so the highest-likelihood, highest-impact risks receive attention first
- Determine the cryptographic key length required by policy
- Replace the need for control assessments
Correct answer: Prioritize risks so the highest-likelihood, highest-impact risks receive attention first
Rating likelihood and impact lets the ISSEP prioritize risks so the highest-likelihood, highest-impact risks receive attention first. Combining the two dimensions, often on a risk matrix, produces a comparable risk level that drives resource allocation and risk-response decisions rather than dictating key lengths or boundaries.
- A program must choose between 'qualitative' and 'quantitative' risk assessment. The key difference the ISSEP should communicate is that:
- Qualitative assessment always produces a precise dollar figure, while quantitative assessment uses only narrative descriptions
- Qualitative assessment requires actuarial loss data, while quantitative assessment never does
- Quantitative assessment assigns numeric, often monetary, values to likelihood and impact, while qualitative assessment uses descriptive relative ratings such as low, moderate, and high
- Quantitative assessment is forbidden in federal systems, while qualitative is mandatory
Correct answer: Quantitative assessment assigns numeric, often monetary, values to likelihood and impact, while qualitative assessment uses descriptive relative ratings such as low, moderate, and high
Quantitative assessment assigns numeric, often monetary, values to likelihood and impact, while qualitative assessment uses descriptive relative ratings such as low, moderate, and high. Quantitative methods give precise, comparable figures when good data exists; qualitative methods are faster and practical when reliable probability and loss data are scarce.
- An ISSEP is asked when a 'semi-quantitative' scale (for example, scoring risk from 0 to 100 binned into bands) is most appropriate. The best answer is when:
- The team wants more granularity and comparability than purely qualitative labels but lacks the data for fully monetary quantitative analysis
- The system has no identifiable assets to protect
- The organization has complete actuarial loss data and demands exact dollar figures
- Regulations prohibit any numeric representation of risk
Correct answer: The team wants more granularity and comparability than purely qualitative labels but lacks the data for fully monetary quantitative analysis
A semi-quantitative scale fits when the team wants more granularity and comparability than purely qualitative labels but lacks the data for fully monetary quantitative analysis. SP 800-30 recognizes semi-quantitative bins as a middle ground that improves consistency and ranking while acknowledging the underlying uncertainty.
- After analyzing a risk, the ISSEP must recommend a 'risk treatment' option. Which set correctly lists the standard risk treatment options?
- Categorize, select, implement, and assess
- Identify, analyze, evaluate, and report
- Encrypt, log, monitor, and patch
- Accept, avoid, mitigate (reduce), and transfer (share)
Correct answer: Accept, avoid, mitigate (reduce), and transfer (share)
The standard risk treatment options are accept, avoid, mitigate (reduce), and transfer (share). These are the courses of action chosen after risk analysis; encrypt/log/monitor/patch are specific controls, and the other lists describe RMF steps or risk-assessment phases, not treatment choices.
- A business unit decides to discontinue a planned feature entirely because its risk exceeds the organization's tolerance and cannot be cost-effectively reduced. Which risk treatment option does this represent?
- Acceptance
- Transfer
- Avoidance
- Mitigation
Correct answer: Avoidance
Eliminating the activity that creates the risk is risk avoidance. The organization chooses not to engage in the risky undertaking at all; this differs from acceptance (proceeding and absorbing the risk), transfer (shifting the loss to another party), and mitigation (applying controls to reduce the risk while still proceeding).
- An organization purchases cyber insurance and contractually shifts certain financial losses to a third party. In risk-treatment terms, this is an example of:
- Risk avoidance
- Risk acceptance
- Risk mitigation
- Risk transfer (sharing)
Correct answer: Risk transfer (sharing)
Purchasing insurance or contractually shifting losses to another party is risk transfer, also called sharing. The likelihood of the event is unchanged, but the financial consequence is moved to the insurer or partner; this is distinct from avoiding the activity, accepting the loss internally, or reducing it through technical controls.
- An ISSEP is briefing on how 'plan of action and milestones' artifacts feed ongoing authorization. Which statement is most accurate?
- Open POA&M items and their projected closure dates inform whether residual risk remains acceptable and whether an ongoing authorization should continue
- POA&M items are confidential to the assessor and are never shared with the authorizing official
- A POA&M is only required for systems categorized as low impact
- Once a POA&M is created, the system must immediately be removed from operation
Correct answer: Open POA&M items and their projected closure dates inform whether residual risk remains acceptable and whether an ongoing authorization should continue
Open POA&M items and their projected closure dates inform whether residual risk remains acceptable and whether an ongoing authorization should continue. The authorizing official reviews POA&M status as part of continuous monitoring; the artifact supports informed, ongoing risk decisions rather than triggering automatic shutdown or being hidden from leadership.
- In a DoD or IC engineering context, an ISSEP integrates risk management into the acquisition life cycle. The most effective approach is to:
- Outsource all risk decisions to the prime contractor without government oversight
- Defer all risk analysis until the system reaches the operations phase
- Conduct a single risk assessment at final acceptance and not before
- Begin risk identification and protection-need analysis in the earliest concept and requirements phases so risk decisions shape design rather than reacting to it
Correct answer: Begin risk identification and protection-need analysis in the earliest concept and requirements phases so risk decisions shape design rather than reacting to it
Risk management is most effective when risk identification and protection-need analysis begin in the earliest concept and requirements phases so risk decisions shape the design. Deferring risk analysis to operations or final acceptance forces costly retrofits, and government authorizing officials retain ownership of risk acceptance even when a contractor performs the work.
- An ISSEP is selecting a 'risk assessment methodology' and wants results that are repeatable across assessors and systems. The most important property to ensure this is that the methodology:
- Avoids documenting assumptions to keep the assessment flexible
- Produces a different risk scale for every system assessed
- Uses clearly defined, documented criteria for rating threat likelihood and impact so different assessors reach consistent conclusions
- Relies on each assessor's intuition without written criteria
Correct answer: Uses clearly defined, documented criteria for rating threat likelihood and impact so different assessors reach consistent conclusions
Repeatability comes from clearly defined, documented criteria for rating threat likelihood and impact so different assessors reach consistent conclusions. Documented assumptions and consistent scales are what make a methodology defensible and comparable; intuition-driven, undocumented approaches yield inconsistent, non-reproducible results.
- Within NIST SP 800-30, the ISSEP frames adversarial threat likelihood by considering the adversary's capability, intent, and:
- Number of employees
- Preferred programming language
- Targeting of the organization or system
- Annual maintenance budget
Correct answer: Targeting of the organization or system
For adversarial threats, SP 800-30 characterizes the threat source by capability, intent, and targeting. Together these help estimate the likelihood of threat initiation; an adversary must be able to act, motivated to act, and aimed at this organization or system for the event to be likely.
- A non-adversarial 'threat source' that an ISSEP must still account for in a risk assessment would include:
- Only an insider deliberately exfiltrating data
- Only a nation-state hacking group
- Only organized criminal malware operators
- An accidental misconfiguration by an authorized administrator or an equipment failure
Correct answer: An accidental misconfiguration by an authorized administrator or an equipment failure
Non-adversarial threat sources include accidental actions such as a misconfiguration by an authorized administrator, as well as structural failures and environmental events. SP 800-30 explicitly covers adversarial, accidental, structural, and environmental sources, so an assessment limited to deliberate attackers would be incomplete.
- An ISSEP wants threat-modeling output to directly influence engineering. The best practice is to:
- Keep the threat model separate from requirements to avoid scope creep
- Trace each identified threat to one or more derived security requirements or design countermeasures so the model drives verifiable protections
- Archive the threat model and revisit it only after a breach
- Use the threat model solely to justify the security budget
Correct answer: Trace each identified threat to one or more derived security requirements or design countermeasures so the model drives verifiable protections
Threat-modeling output should be traced to derived security requirements or design countermeasures so the model drives verifiable protections. Linking threats to requirements ensures the analysis changes the system rather than sitting as a document; treating it as budget justification or a post-breach artifact wastes its preventive value.
- An organization sets a 'risk tolerance' statement that interruptions to a critical service longer than five minutes during core hours must be avoided. The ISSEP should use this statement to:
- Set the system's confidentiality categorization to high
- Replace the need for a risk assessment entirely
- Determine the procurement vendor selection
- Drive availability requirements and acceptance criteria so the engineered solution keeps risk within the tolerated bound
Correct answer: Drive availability requirements and acceptance criteria so the engineered solution keeps risk within the tolerated bound
A specific risk tolerance statement should drive availability requirements and acceptance criteria so the engineered solution keeps risk within the tolerated bound. Tolerance statements are measurable targets that translate appetite into verifiable engineering objectives; they do not by themselves set categorization or vendor choices.
- When an ISSEP rolls system-level cybersecurity risks up into 'enterprise risk management,' a common challenge is that:
- Cybersecurity risks are always larger than every other enterprise risk by definition
- Each system must use a unique, non-comparable risk scale
- Cybersecurity risks must be normalized into comparable terms so leadership can weigh them against non-cyber enterprise risks
- Enterprise leadership has no role in accepting cybersecurity risk
Correct answer: Cybersecurity risks must be normalized into comparable terms so leadership can weigh them against non-cyber enterprise risks
A common challenge is that cybersecurity risks must be normalized into comparable terms so leadership can weigh them against non-cyber enterprise risks. NIST IR 8286 stresses that without a consistent expression of risk, cyber concerns cannot be prioritized alongside financial, legal, and operational risks at the enterprise level.
- During quantitative analysis, an ISSEP computes a Single Loss Expectancy of 50,000 dollars for a server outage with an Annualized Rate of Occurrence of 0.5. The resulting Annualized Loss Expectancy is:
- 100,000 dollars
- 50,000 dollars
- 12,500 dollars
- 25,000 dollars
Correct answer: 25,000 dollars
Annualized Loss Expectancy equals Single Loss Expectancy multiplied by Annualized Rate of Occurrence, so 50,000 times 0.5 yields 25,000 dollars. This quantitative figure helps compare the expected annual cost of the risk against the cost of controls to support a cost-justified treatment decision.
- An ISSEP must decide whether identified residual risk is acceptable. The correct basis for that judgment is to:
- Compare the residual risk against the organization's documented risk tolerance and appetite
- Compare it only against the cost of the cheapest available control
- Defer the judgment to the system integrator's preference
- Accept any residual risk because some risk always remains
Correct answer: Compare the residual risk against the organization's documented risk tolerance and appetite
Residual risk is judged acceptable by comparing it against the organization's documented risk tolerance and appetite. That comparison gives the authorizing official a defensible, consistent basis for the decision; cost alone, blanket acceptance, or deferral to the integrator does not align the decision with enterprise risk guidance.
- An ISSEP wants to ensure a threat model remains accurate as a system evolves. The most appropriate practice is to:
- Maintain the threat model only for low-impact systems
- Update the threat model when significant architecture, data flows, or the threat environment change so it continues to reflect actual risk
- Treat the threat model as a fixed artifact never revisited after initial design
- Replace the threat model with the penetration test report once testing begins
Correct answer: Update the threat model when significant architecture, data flows, or the threat environment change so it continues to reflect actual risk
A threat model should be updated when significant architecture, data flows, or the threat environment change so it continues to reflect actual risk. Threat modeling is iterative across the life cycle; a static model quickly becomes inaccurate as the system and adversary landscape evolve, undermining the risk decisions built on it.
- An ISSEP recommends 'mitigation' as the treatment for a high risk. Mitigation reduces risk by:
- Shifting the financial loss to an insurer
- Applying controls that lower the likelihood of the threat event, its impact, or both, leaving an accepted residual risk
- Documenting the risk and proceeding with no change
- Eliminating the activity that produces the risk entirely
Correct answer: Applying controls that lower the likelihood of the threat event, its impact, or both, leaving an accepted residual risk
Mitigation applies controls that lower the likelihood of the threat event, its impact, or both, leaving an accepted residual risk. It differs from avoidance (stopping the activity), transfer (shifting loss to another party), and acceptance (proceeding without change); mitigation is the active reduction of risk through engineered safeguards.
- An ISSEP is leading the security planning effort for a new federal mission system. According to the NIST Risk Management Framework, what is the correct sequence of activities that drives the selection of an initial security control set?
- Authorize the system, then categorize it, then implement controls
- Categorize the system, then select a control baseline, then tailor it
- Tailor a baseline, then categorize the system, then assess controls
- Implement vendor defaults, then categorize, then document residual risk
Correct answer: Categorize the system, then select a control baseline, then tailor it
Categorizing the system, then selecting a control baseline, then tailoring it is the correct planning sequence. Under the RMF, security categorization (FIPS 199) sets the impact level, which determines the low, moderate, or high baseline drawn from SP 800-53B, and that baseline is then tailored to the system. Authorization and assessment occur later, so any sequence beginning with authorize or tailoring before categorization is out of order.
- During security planning, an information system processes data whose unauthorized disclosure would cause limited harm (low confidentiality impact), but whose corruption would cause serious harm (high integrity impact), and whose loss would cause limited harm (low availability impact). Applying FIPS 199, what overall security categorization should the ISSEP assign before selecting a baseline?
- High, using the high water mark of the impact values
- Moderate, by averaging the three impact values
- It cannot be categorized until controls are selected
- Low, because two of the three objectives are low
Correct answer: High, using the high water mark of the impact values
High is correct, because FIPS 199 applies the high water mark, taking the highest impact value among confidentiality, integrity, and availability. Since integrity is high, the overall system categorization is high regardless of the lower confidentiality and availability values. Averaging or counting the majority of objectives is not how FIPS 199 categorization works.
- An ISSEP must choose the starting set of controls for a moderate-impact system. Which NIST publication provides the security control baselines (low, moderate, high) and the tailoring guidance that the ISSEP applies during the planning effort?
- NIST SP 800-53B
- NIST SP 800-30
- NIST SP 800-61
- FIPS 140-3
Correct answer: NIST SP 800-53B
NIST SP 800-53B is correct; it defines the low-, moderate-, and high-impact control baselines plus a privacy baseline and the associated tailoring guidance. SP 800-53 itself defines the control catalog, while SP 800-53B organizes those controls into the baselines used for selection. FIPS 140-3 addresses cryptographic modules, SP 800-30 covers risk assessment, and SP 800-61 covers incident handling.
- After selecting the moderate baseline, the ISSEP refines it by designating common controls, applying scoping considerations, selecting compensating controls, and assigning values to organization-defined parameters. What is the collective name for this refinement activity in SP 800-53B?
- Continuous monitoring
- Categorization
- Tailoring
- Authorization
Correct answer: Tailoring
Tailoring is correct. SP 800-53B defines tailoring as the disciplined process of customizing a baseline through scoping decisions, identifying common controls, selecting compensating controls, supplementing with additional controls, and assigning organization-defined parameter values. Categorization precedes baseline selection, while authorization and continuous monitoring occur in later RMF steps.
- While tailoring the baseline, an ISSEP determines that a required control is not technically feasible for a legacy device but a different control can achieve an equivalent protective effect. What tailoring action is the ISSEP applying?
- Issuing a plan of action and milestones
- Performing security categorization
- Selecting a compensating control
- Establishing the authorization boundary
Correct answer: Selecting a compensating control
Selecting a compensating control is correct. When a baseline control cannot be implemented as specified, tailoring permits substituting an alternative (compensating) control that provides equivalent protection, with documented justification. Categorization and boundary definition are separate planning activities, and a plan of action and milestones tracks deficiencies rather than substituting a control.
- An ISSEP is documenting how each selected control will be implemented. One control will be fully provided by an enterprise identity service shared across many systems and inherited without local effort. How should this control be designated?
- A hybrid control
- A compensating control
- A common control
- A system-specific control
Correct answer: A common control
A common control is correct. Per SP 800-37, a common control is one fully provided by an organizational entity (a common control provider) and inherited by systems without the system owner implementing it locally. A system-specific control is the system owner's full responsibility, and a hybrid control is shared between the provider and the system owner.
- During planning, the ISSEP finds that an enterprise audit-logging service satisfies part of a control, but the system must still configure its own application-level event capture to fully meet the requirement. How is this control classified?
- A hybrid control
- A system-specific control
- A common control
- An inherited control with no system responsibility
Correct answer: A hybrid control
A hybrid control is correct. SP 800-37 defines a hybrid control as one in which part of the requirement is provided by a common control provider for inheritance and part must be implemented at the system level. Because the system retains responsibility for application-level logging, it is neither fully common nor fully system-specific.
- An ISSEP wants to reduce the implementation and assessment workload across a portfolio of systems by maximizing the controls that systems can inherit. What is the primary benefit of security control inheritance when planning these systems?
- It transfers all residual risk to the cloud vendor automatically
- It lets systems inherit controls implemented and assessed once by a provider, reducing duplicate effort
- It eliminates the authorization requirement for inheriting systems
- It removes the need to categorize each system
Correct answer: It lets systems inherit controls implemented and assessed once by a provider, reducing duplicate effort
Letting systems inherit controls implemented and assessed once by a provider is correct. Control inheritance means a common control provider implements, assesses, and maintains a control, and multiple systems consume the resulting protection and evidence, reducing duplicated work. Inheritance does not remove categorization, authorization, or the inheriting owner's duty to confirm the inherited control meets system needs.
- An ISSEP plans to inherit a set of common controls from an enterprise provider. Before relying on them, what must the ISSEP confirm to responsibly use security control inheritance?
- That the inherited controls actually satisfy the inheriting system's requirements and the provider's assessment evidence supports them
- That the inherited controls are re-implemented locally to be safe
- That inheritance automatically grants the system an authorization to operate
- That the provider's controls have never been assessed
Correct answer: That the inherited controls actually satisfy the inheriting system's requirements and the provider's assessment evidence supports them
Confirming the inherited controls satisfy the system's requirements and are supported by the provider's assessment evidence is correct. Inheritance shifts implementation to the provider but the inheriting system owner remains accountable for verifying that the controls meet the system's needs and that current assessment results back them. Re-implementing locally defeats the purpose, and inheritance does not grant an authorization.
- An ISSEP is decomposing a high-level protection need into a structured set of derived security requirements allocated to system elements. The team wants assurance that no requirement is lost and that each can be traced forward to a design element and backward to its source. What practice provides this assurance?
- Disposal planning
- Security requirements traceability
- Penetration testing
- Security categorization
Correct answer: Security requirements traceability
Security requirements traceability is correct. Maintaining bidirectional traceability links each requirement to its originating need and forward to design, implementation, and verification, ensuring completeness and supporting impact analysis when changes occur. Categorization, penetration testing, and disposal planning serve other purposes and do not establish requirement-to-design linkage.
- When an ISSEP allocates derived security requirements during architecture and design, what is the central engineering objective of requirements allocation?
- To assign every requirement to the perimeter firewall
- To distribute requirements randomly to improve resilience
- To defer requirements until after the system is operational
- To assign each requirement to the specific system element(s) responsible for satisfying it while preserving traceability
Correct answer: To assign each requirement to the specific system element(s) responsible for satisfying it while preserving traceability
Assigning each requirement to the specific element(s) responsible for satisfying it while preserving traceability is correct. Allocation maps requirements onto the architecture so accountability is clear and verification is possible, and it maintains the traceability needed for change management. Concentrating requirements on one device, randomizing them, or deferring them undermines disciplined engineering.
- An ISSEP designs an account model in which a maintenance process is granted only the file and network permissions strictly necessary to perform updates, and nothing more. Which security design principle is being applied?
- Defense in depth
- Open design
- Economy of mechanism
- Least privilege
Correct answer: Least privilege
Least privilege is correct. Least privilege requires that each subject (user, process, or service) operate with only the minimum rights needed to perform its function, limiting the damage from errors or compromise. Defense in depth layers diverse protections, open design avoids reliance on secrecy of mechanism, and economy of mechanism favors simplicity; none specifically describes minimizing granted permissions.
- An ISSEP is justifying the principle of least privilege to a program manager who wants to give all operators administrator rights for convenience. What is the strongest security rationale the ISSEP can give?
- It removes the requirement to categorize the system
- It reduces the potential damage from accidents, malware, or insider misuse by limiting what any compromised account can do
- It eliminates the need for audit logging
- It guarantees the system will never be breached
Correct answer: It reduces the potential damage from accidents, malware, or insider misuse by limiting what any compromised account can do
Reducing potential damage by limiting what any compromised account can do is correct. Least privilege confines the blast radius of a compromised or misused account, so an attacker or a careless operator can affect only the narrow scope the account was granted. It does not guarantee zero breaches, replace audit logging, or change categorization obligations.
- An ISSEP designs an architecture with a screening router, a network firewall, host-based controls, application input validation, and encryption of data at rest, so that no single failure exposes the asset. Which strategy does this layered, diverse arrangement represent?
- Single sign-on
- Defense in depth
- Fail-open design
- Least common mechanism
Correct answer: Defense in depth
Defense in depth is correct. Defense in depth places multiple, diverse, and complementary safeguards along potential attack paths so that the failure or bypass of one layer is mitigated by others, increasing attacker work factor. Single sign-on addresses authentication convenience, fail-open is an availability-favoring failure mode, and least common mechanism minimizes shared resources.
- A reviewer argues that the new architecture is secure because it has a very strong perimeter firewall. As an ISSEP applying defense in depth architecture, what is the most accurate critique?
- Internal controls are unnecessary once the perimeter is hardened
- Relying on one layer creates a single point of failure; protections should be layered so internal compromise is still contained
- Defense in depth means deploying identical firewalls in series
- A single strong perimeter is sufficient if it is expensive enough
Correct answer: Relying on one layer creates a single point of failure; protections should be layered so internal compromise is still contained
Noting that one layer is a single point of failure and protections should be layered to contain internal compromise is correct. A defense in depth architecture assumes any single control can fail or be bypassed, so it adds diverse internal and data-level protections rather than trusting one boundary. Stacking identical firewalls adds cost without diversity and does not embody the principle.
- An ISSEP designs a payment workflow so that the person who initiates a payment cannot also approve and release it; two distinct roles are required. Which security design principle does this enforce?
- Complete mediation
- Psychological acceptability
- Separation of duties
- Economy of mechanism
Correct answer: Separation of duties
Separation of duties is correct. Separation of duties divides a critical task among multiple parties so that no single individual can both perform and conceal a fraudulent or erroneous action. Complete mediation concerns checking every access, psychological acceptability concerns usability of controls, and economy of mechanism concerns simplicity.
- How does an ISSEP distinguish the principle of separation of duties from the principle of least privilege when planning a sensitive process?
- Least privilege requires two approvers, while separation of duties limits permissions
- They are the same principle with different names
- Separation of duties divides a task among people so no one controls it end to end, while least privilege limits the rights each subject holds
- Both apply only to physical security, not information systems
Correct answer: Separation of duties divides a task among people so no one controls it end to end, while least privilege limits the rights each subject holds
The distinction that separation of duties divides a task among people while least privilege limits each subject's rights is correct. Separation of duties prevents any single actor from completing a high-risk transaction alone, whereas least privilege restricts the scope of access any one subject is granted. They are complementary but distinct, and both apply directly to information systems, not only physical security.
- An ISSEP is selecting controls from NIST SP 800-53. Within the catalog, what is the relationship between a base control and a control enhancement?
- A base control is optional while an enhancement is always mandatory
- An enhancement adds functionality or increases the strength of, or specificity for, a related base control
- Enhancements apply only to privacy controls, not security controls
- An enhancement replaces the base control entirely
Correct answer: An enhancement adds functionality or increases the strength of, or specificity for, a related base control
An enhancement adding functionality or increasing the strength or specificity of a related base control is correct. In SP 800-53, control enhancements build on a base control, identified by the base number plus a parenthetical, and a baseline may select the base plus specific enhancements. Enhancements do not replace base controls and are not limited to privacy controls.
- A control in SP 800-53 includes a bracketed assignment such as the frequency at which a backup must occur. When the ISSEP fills in this value during planning, what is the ISSEP defining?
- A FIPS 199 impact level
- A compensating control
- A residual risk statement
- An organization-defined parameter
Correct answer: An organization-defined parameter
An organization-defined parameter is correct. Many SP 800-53 controls contain assignment or selection statements that the organization must populate (for example, a frequency or threshold), and assigning these values is part of tailoring. A compensating control substitutes for an infeasible control, a residual risk statement documents remaining risk, and a FIPS 199 impact level is set during categorization.
- An ISSEP needs to select the audit-related controls and the configuration-baseline controls for a system. In SP 800-53, controls are grouped by two-letter codes. Which pairing correctly identifies these families?
- AC for Audit and Accountability and CP for Configuration Management
- AU for Audit and Accountability and CM for Configuration Management
- IA for Audit and Accountability and SC for Configuration Management
- AU for Access Control and CA for Configuration Management
Correct answer: AU for Audit and Accountability and CM for Configuration Management
AU for Audit and Accountability and CM for Configuration Management is correct. SP 800-53 organizes controls into families identified by two-letter codes; AU covers audit and accountability and CM covers configuration management. AC is Access Control, CP is Contingency Planning, IA is Identification and Authentication, and SC is System and Communications Protection.
- An ISSEP must select the initial control set for a high-impact system. Which factor most directly determines which SP 800-53B baseline (low, moderate, or high) is selected?
- The number of users on the system
- The system's security categorization (impact level)
- The penetration test schedule
- The vendor's product roadmap
Correct answer: The system's security categorization (impact level)
The system's security categorization is correct. The impact level produced by FIPS 199 categorization maps directly to the corresponding SP 800-53B baseline (low, moderate, or high), which provides the starting control set before tailoring. User count, vendor roadmaps, and testing schedules do not determine baseline selection.
- An ISSEP is explaining the order of operations to a team that wants to select controls before doing anything else. What activity must occur before security control selection so that the right baseline can be chosen?
- Security categorization
- System disposal planning
- Continuous monitoring
- Penetration testing
Correct answer: Security categorization
Security categorization is correct. Categorization establishes the impact level that determines which baseline is selected, so it necessarily precedes control selection in the RMF. Continuous monitoring and disposal occur later in the life cycle, and penetration testing is part of assessment rather than a prerequisite for selecting a baseline.
- In SP 800-160 Volume 1, an ISSEP performs the requirements analysis and architecture definition activities. What is the principal output that connects stakeholder protection needs to the structure of the solution?
- A set of derived security requirements and a security architecture that allocates them to elements
- A signed authorization to operate
- A continuous monitoring dashboard
- A vendor purchase order
Correct answer: A set of derived security requirements and a security architecture that allocates them to elements
A set of derived security requirements and a security architecture that allocates them to elements is correct. In the SP 800-160 life-cycle processes, protection needs are decomposed into derived requirements, and architecture definition allocates those requirements across the system structure, forming the bridge from need to design. Authorization, procurement, and monitoring artifacts are produced in other activities.
- An ISSEP is documenting how security requirements, trust boundaries, and protections relate to the operational and systems views of a federal enterprise architecture. What artifact best captures these security-relevant relationships across the other architecture views?
- A security view (security architecture overlay) of the enterprise architecture
- A network cabling diagram
- A software license inventory
- A staffing plan
Correct answer: A security view (security architecture overlay) of the enterprise architecture
A security view of the enterprise architecture is correct. A security view (or security architecture overlay) expresses security requirements, controls, trust boundaries, and constraints and relates them to the operational, systems, and technical views so protection is coherent across the architecture. Cabling diagrams, license inventories, and staffing plans do not integrate security across views.
- When applying recognized security design principles, an ISSEP wants the protection of the system to remain effective even if an adversary fully understands the design, with secrecy limited to cryptographic keys. Which principle captures this?
- Fail-open defaults
- Security through obscurity
- Maximized sharing of mechanisms
- Open design
Correct answer: Open design
Open design is correct. The open design principle holds that security must not depend on the secrecy of the mechanism or design; protection should hold even when the design is known, with secrecy confined to keys. Security through obscurity is the rejected opposite, fail-open is an unsafe default, and maximizing shared mechanisms contradicts least common mechanism.
- An ISSEP reviews a design and recommends keeping the protection mechanism as simple and small as practical so it can be more readily analyzed and verified. Which security design principle supports this recommendation?
- Economy of mechanism
- Complete mediation
- Defense in depth
- Separation of duties
Correct answer: Economy of mechanism
Economy of mechanism is correct. This principle favors simplicity and minimal size in security mechanisms because simpler designs are easier to analyze, test, and verify, reducing latent flaws. Defense in depth concerns layering, separation of duties concerns dividing tasks, and complete mediation concerns checking every access.
- During design, an ISSEP requires that every reference to a protected object be checked against the authorization policy rather than caching an earlier decision. Which design principle is being enforced?
- Psychological acceptability
- Least common mechanism
- Open design
- Complete mediation
Correct answer: Complete mediation
Complete mediation is correct. Complete mediation requires that every access to every protected object be validated against the current authorization policy, preventing reliance on stale or bypassed permission decisions. Least common mechanism minimizes shared resources, open design rejects secrecy of mechanism, and psychological acceptability concerns usability.
- An ISSEP is establishing a system security plan during the planning phase. Which content is most essential for the plan to support later control assessment and authorization?
- The personal contact details of every end user
- The marketing positioning of the system
- Only a list of approved hardware vendors
- The system categorization, the selected and tailored controls, and how each control is implemented
Correct answer: The system categorization, the selected and tailored controls, and how each control is implemented
Capturing the categorization, the selected and tailored controls, and how each control is implemented is correct. The system security plan documents the security categorization, control selection and tailoring decisions, and implementation descriptions, providing the basis for assessment and authorization. Marketing content, a bare vendor list, or user contact details do not fulfill the plan's purpose.
- An ISSEP is mapping the cross-domain solution into the architecture. A controlled interface that enforces information-flow policy between two security domains of differing trust or classification is best designed as which element?
- A guard
- A patch management server
- A load balancer
- A backup appliance
Correct answer: A guard
A guard is correct. In a cross-domain solution, a guard is the controlled interface that inspects, filters, and enforces information-flow policy between domains of differing trust or classification, allowing only authorized transfers. Load balancers, backup appliances, and patch servers serve operational functions but do not enforce cross-domain flow policy.
- An ISSEP supplements a tailored baseline with an organization-defined overlay to address a specialized operating environment, such as a classified national security system. What is the purpose of applying an overlay during control selection?
- To provide a fully specified, community- or mission-specific set of tailoring decisions applied on top of a baseline
- To eliminate the need for assessment
- To remove the requirement for categorization
- To replace the system security plan
Correct answer: To provide a fully specified, community- or mission-specific set of tailoring decisions applied on top of a baseline
Providing a community- or mission-specific set of tailoring decisions applied on top of a baseline is correct. An overlay packages predefined scoping, parameter, and supplementation decisions tailored for a specific environment, technology, or community, applied after baseline selection. Overlays do not remove categorization, replace the security plan, or eliminate assessment.
- An ISSEP needs to ensure that a derived security requirement can be confirmed during verification. Which set of attributes best describes a well-formed security requirement that supports traceability and testing?
- Unambiguous, verifiable, traceable, and feasible
- Ambiguous, untestable, and broad to allow flexibility
- Limited to a single hardware vendor
- Written only after the system is deployed
Correct answer: Unambiguous, verifiable, traceable, and feasible
Unambiguous, verifiable, traceable, and feasible is correct. Quality security requirements must be clear, testable, linked to a source need, and achievable, which is what makes them verifiable and supports a requirements traceability matrix. Ambiguity, post-deployment authoring, or vendor-locking undermine traceability and verification.
- An ISSEP is allocating security requirements to a system of systems where some requirements span multiple subsystems. What is the most disciplined way to handle a requirement that cannot be satisfied by a single element?
- Defer allocation until after authorization
- Drop the requirement because it is inconvenient
- Assign the entire requirement to the most expensive component
- Decompose it into sub-requirements allocated to each contributing element, maintaining traceability to the parent
Correct answer: Decompose it into sub-requirements allocated to each contributing element, maintaining traceability to the parent
Decomposing it into sub-requirements allocated to each contributing element while maintaining traceability is correct. When a requirement spans elements, the ISSEP refines it into allocatable sub-requirements, assigns each to a responsible element, and preserves linkage to the parent so completeness and verification are intact. Dropping, arbitrarily concentrating, or deferring the requirement breaks disciplined allocation.
- An ISSEP is planning controls for a moderate-impact system and applies a scoping consideration that a particular control does not apply because the system has no wireless capability. Which tailoring action does this represent?
- Applying a scoping consideration to remove a non-applicable control
- Adding a compensating control
- Performing the high water mark categorization
- Assigning an organization-defined parameter
Correct answer: Applying a scoping consideration to remove a non-applicable control
Applying a scoping consideration to remove a non-applicable control is correct. Scoping considerations in SP 800-53B let an organization justify that a baseline control is not applicable to the system (for example, a wireless control on a system with no wireless), with documented rationale. This differs from selecting a compensating control, assigning parameters, or categorizing the system.
- An ISSEP is explaining the difference between verification and validation to a project team. Which statement most accurately captures the distinction?
- Verification occurs only after deployment, while validation occurs only during requirements definition
- Verification is performed by an independent third party, while validation is always performed by the development team
- Verification measures availability, while validation measures confidentiality
- Verification confirms the system was built according to its specified requirements, while validation confirms the system fulfills the stakeholders' actual needs and intended use
Correct answer: Verification confirms the system was built according to its specified requirements, while validation confirms the system fulfills the stakeholders' actual needs and intended use
Confirming the system was built to its specified requirements (verification) versus confirming it meets stakeholder needs and intended use (validation) is the correct distinction. Verification answers 'did we build the system right?' against the documented specification, while validation answers 'did we build the right system?' against the operational mission and real protection needs. The other choices confuse who performs the work or when it occurs, which is not what defines the two activities.
- A program office requires that the team assessing whether a system's security controls function correctly must report to a chain separate from the developers who built the system. This arrangement is best described as:
- Independent verification and validation (IV&V)
- Configuration baselining
- Continuous integration
- Security categorization
Correct answer: Independent verification and validation (IV&V)
An assessment team organizationally and financially separate from the developers performing verification and validation is independent verification and validation (IV&V). IV&V provides objective, conflict-free evidence about whether the system meets requirements and stakeholder needs, increasing credibility of the results. Continuous integration and configuration baselining are implementation/build practices, and categorization happens far earlier in the life cycle.
- A CISSP candidate asks an ISSEP, 'What is an ATO?' The most accurate answer is that an authorization to operate is:
- A technical certificate installed on servers to enable encrypted connections
- A vendor warranty guaranteeing the system has no remaining vulnerabilities
- A contractual milestone that releases payment to the system integrator
- An official management decision by a senior official to authorize operation of a system and to explicitly accept the residual risk to the organization
Correct answer: An official management decision by a senior official to authorize operation of a system and to explicitly accept the residual risk to the organization
An authorization to operate (ATO) is a senior official's formal decision to authorize operation of a system and to accept the residual risk to organizational operations, assets, and individuals. It is a risk-based management decision, not a technical artifact, warranty, or payment trigger. The other options confuse the ATO with cryptographic certificates or commercial terms.
- Under the NIST Risk Management Framework, the senior official who reviews the assessment evidence and renders the authorization to operate decision is the:
- Common control provider
- Information system security engineer
- Authorizing official (AO)
- Security control assessor
Correct answer: Authorizing official (AO)
The authorizing official (AO) holds the authority and accountability to grant, deny, or revoke an authorization to operate after weighing residual risk. The security control assessor evaluates controls and produces evidence but does not decide; the ISSE engineers the solution; the common control provider supplies inherited controls. Only the AO formally accepts risk on behalf of the organization.
- A legacy federal program still references 'certification and accreditation' (C&A). When mapping this to current NIST terminology, certification corresponds most closely to which activity?
- The senior official's decision to accept residual risk and permit operation
- The categorization of the system based on FIPS 199 impact levels
- The comprehensive assessment of security controls to determine whether they are implemented correctly and operating as intended
- The disposal and media sanitization of decommissioned assets
Correct answer: The comprehensive assessment of security controls to determine whether they are implemented correctly and operating as intended
In the older C&A model, certification is the technical evaluation that controls are implemented correctly and operating as intended, which maps to today's security control assessment. Accreditation, the management decision to accept risk and authorize operation, maps to the modern authorization (ATO). Categorization and disposal are separate life-cycle activities, not the certification step.
- A test lead asks the ISSEP to clarify the difference between a vulnerability assessment and a penetration test for the verification effort. Which distinction is correct?
- A vulnerability assessment identifies and catalogs weaknesses broadly, while a penetration test actively attempts to exploit selected weaknesses to demonstrate real-world impact
- A vulnerability assessment exploits flaws to prove impact, while a penetration test only lists missing patches
- Both are identical activities performed by the same automated scanner
- A penetration test only reviews documentation, while a vulnerability assessment only tests the live system
Correct answer: A vulnerability assessment identifies and catalogs weaknesses broadly, while a penetration test actively attempts to exploit selected weaknesses to demonstrate real-world impact
A vulnerability assessment broadly identifies and catalogs weaknesses, while a penetration test goes further by actively exploiting selected weaknesses under rules of engagement to demonstrate concrete impact and validate defenses. The assessment is breadth-oriented; the test is depth- and impact-oriented. The reversed and 'identical' options misstate each method's purpose.
- Per NIST SP 800-53A, a security control assessment determines whether controls are:
- Installed faster than the project schedule required
- Implemented correctly, operating as intended, and producing the desired outcome with respect to meeting security requirements
- Documented in the marketing literature provided by the vendor
- Cheaper than the alternatives considered during procurement
Correct answer: Implemented correctly, operating as intended, and producing the desired outcome with respect to meeting security requirements
A security control assessment determines whether each control is implemented correctly, operating as intended, and producing the desired outcome relative to the security requirements. This three-part test is the core standard in SP 800-53A. Cost, vendor literature, and installation speed are not what an assessment evaluates.
- An ISSEP is preparing the document that defines the scope, assessment procedures, schedule, roles, and assessment environment before controls are evaluated. This artifact is the:
- System security plan (SSP)
- Interconnection security agreement (ISA)
- Security assessment plan (SAP)
- Plan of action and milestones (POA&M)
Correct answer: Security assessment plan (SAP)
The security assessment plan (SAP) defines the scope, assessment procedures, schedule, assessor roles, and the environment for evaluating controls before assessment begins. The POA&M tracks remediation of weaknesses found afterward, the SSP describes the system and its controls, and the ISA governs connections between systems. Only the SAP sets up how the assessment will be conducted.
- In a DoD or IC engineering context, 'security test and evaluation' (ST&E) is best characterized as:
- A personnel clearance adjudication for system administrators
- The examination and testing of security controls and safeguards to determine whether they meet the system's security requirements before and during operation
- A marketing assessment of competing security products
- A budgeting exercise that allocates funds across program phases
Correct answer: The examination and testing of security controls and safeguards to determine whether they meet the system's security requirements before and during operation
Security test and evaluation (ST&E) is the structured examination and testing of security controls and safeguards to determine whether they satisfy the system's security requirements. It produces evidence that feeds the assessment and authorization decision. Budgeting, clearances, and product marketing are unrelated to the ST&E technical activity.
- The phrase 'systems implementation, verification, and validation' captures the engineering sequence in which the ISSEP first realizes the security solution and then confirms it. Which ordering of underlying intents is correct?
- Accept residual risk, then implement controls, then write the security plan
- Confirm stakeholder needs, then write requirements, then categorize the system
- Dispose of legacy media, then build controls, then categorize impact
- Build the solution into the system, confirm it satisfies specified requirements, then confirm it meets stakeholder needs in its operational context
Correct answer: Build the solution into the system, confirm it satisfies specified requirements, then confirm it meets stakeholder needs in its operational context
Implementation realizes the security solution in the system, verification confirms it satisfies the specified requirements, and validation confirms it meets stakeholder needs in the operational context. This is the intended flow of the implementation, verification, and validation domain. The other sequences scramble life-cycle activities from other domains.
- A team is standing up a CI/CD pipeline for a federal system. To embed security into the pipeline (DevSecOps), the ISSEP's most effective recommendation is to:
- Run all security testing manually after the system is in production
- Disable automated gates so releases are never blocked by findings
- Integrate automated security testing such as SAST, dependency scanning, and policy gates into the build and deployment stages so insecure changes fail the pipeline
- Grant the pipeline service account unrestricted access to simplify deployments
Correct answer: Integrate automated security testing such as SAST, dependency scanning, and policy gates into the build and deployment stages so insecure changes fail the pipeline
Embedding automated security testing (SAST, software composition/dependency scanning, and policy gates) into the build and deployment stages so insecure changes fail the pipeline is the DevSecOps approach. It shifts verification left and enforces security continuously. Deferring all testing to production, over-privileging the pipeline, or removing gates all defeat the purpose of secure CI/CD.
- During integration of multiple separately developed components, the ISSEP observes that each component passed its own unit security tests. Why is integration-level security testing still necessary?
- Component-level tests automatically guarantee the security of the assembled system
- Security is an emergent property, and vulnerabilities can arise from the interactions and interfaces between components that pass tests individually
- Integration testing is only required for hardware, not software
- Unit tests are never trustworthy and must always be discarded
Correct answer: Security is an emergent property, and vulnerabilities can arise from the interactions and interfaces between components that pass tests individually
Because security is an emergent property of the whole, weaknesses frequently appear at the interfaces and in the interactions between components that each passed isolated tests. Integration testing exercises those combined behaviors and trust boundaries. Component tests do not guarantee the assembled system is secure, which is exactly why integration-level verification is required.
- An ISSEP is developing a security test plan. Which element is most essential for ensuring the plan demonstrably covers every security requirement?
- A glossary of marketing terms for the product
- Traceability that maps each security requirement to one or more specific test cases and expected results
- A list of every employee's office phone number
- The vendor's quarterly revenue projections
Correct answer: Traceability that maps each security requirement to one or more specific test cases and expected results
Requirement-to-test-case traceability with expected results is essential so the plan provably exercises every security requirement and nothing is silently dropped. It also lets assessors confirm coverage and tie findings back to specific requirements. Phone lists, revenue projections, and marketing glossaries contribute nothing to test coverage.
- A penetration test is about to begin against a production-adjacent system. Before any testing occurs, the ISSEP insists on agreed rules of engagement primarily to:
- Guarantee that the testers will find every vulnerability in the system
- Define authorized scope, methods, timing, and notification procedures so testing is legal, safe, and bounded
- Allow testers unlimited access to all connected production systems
- Eliminate the need to document any findings afterward
Correct answer: Define authorized scope, methods, timing, and notification procedures so testing is legal, safe, and bounded
Rules of engagement establish authorized scope, permitted methods, timing windows, and notification/escalation procedures so the test is legal, safe, and bounded. They protect both the testers and the organization and keep testing from cascading into unintended systems. Rules of engagement do not guarantee complete coverage, nor do they remove the obligation to document findings.
- After verification testing is complete, the ISSEP is asked to 'review and update the risk analysis.' The most appropriate reason for this step is that:
- Test results may reveal new or residual weaknesses that change the system's actual risk posture before an authorization decision
- Risk analysis is only relevant before any requirements are written
- The risk analysis must always be deleted once testing finishes
- Updating risk analysis replaces the need for the authorizing official
Correct answer: Test results may reveal new or residual weaknesses that change the system's actual risk posture before an authorization decision
Verification results can surface new or residual weaknesses that alter the true risk picture, so the risk analysis must be revisited to reflect what testing actually found before authorization. This gives the authorizing official a current, evidence-based view of residual risk. The step neither deletes the analysis nor substitutes for the AO's decision.
- An ISSEP documents formal stakeholder acceptance at the conclusion of implementation. The primary purpose of capturing this acceptance is to:
- Transfer all future liability for the system to the test team
- Eliminate the requirement for continuous monitoring in operations
- Record that the stakeholders agree the delivered security solution satisfies their needs and acceptance criteria, establishing a basis to proceed
- Replace the authorization to operate decision
Correct answer: Record that the stakeholders agree the delivered security solution satisfies their needs and acceptance criteria, establishing a basis to proceed
Documenting stakeholder acceptance records that the stakeholders agree the delivered solution meets their needs and the agreed acceptance criteria, providing a defensible basis to move forward. It is a validation milestone, not a liability transfer, and it does not remove the need for monitoring or for a formal authorization decision.
- A security control assessment finds a high-severity weakness that cannot be fixed before the go-live date. The most appropriate engineering response is to:
- Disable system logging so the weakness is not detected again
- Quietly remove the affected control from the security plan
- Record the weakness in a POA&M, evaluate residual risk and compensating controls, and let the authorizing official decide
- Mark the control as passed to avoid delaying the schedule
Correct answer: Record the weakness in a POA&M, evaluate residual risk and compensating controls, and let the authorizing official decide
Recording the weakness in a POA&M, assessing residual risk, considering compensating controls, and presenting it to the authorizing official preserves honesty and supports a risk-based decision. Hiding, falsifying, or suppressing the finding undermines the assessment's integrity and the AO's ability to accept risk knowingly.
- When validating a security solution in its operational environment, the ISSEP's central question is:
- Were the firewall rules entered in the correct numerical order?
- Did the source code compile without warnings?
- Were the control parameters typed in correctly?
- Does the system, as deployed in its real operational context, actually satisfy the stakeholders' protection needs and mission objectives?
Correct answer: Does the system, as deployed in its real operational context, actually satisfy the stakeholders' protection needs and mission objectives?
Validation asks whether the deployed system, in its real operational context, actually meets stakeholder protection needs and mission objectives. The other choices are narrow verification checks (rule ordering, compilation, parameter entry) that confirm conformance to specifications but do not establish operational fitness for purpose.
- An ISSEP must choose between conducting a broad automated vulnerability assessment and a focused penetration test for a system with limited assessment time and a need to prove that a critical control can withstand realistic attack. The most defensible choice is to:
- Skip assessment entirely because the control was designed carefully
- Run only an unauthenticated vulnerability scan, since it produces the longest report
- Perform only documentation review, since live testing is unnecessary
- Conduct a focused penetration test against the critical control, since demonstrating real exploitability and defense effectiveness is the stated objective
Correct answer: Conduct a focused penetration test against the critical control, since demonstrating real exploitability and defense effectiveness is the stated objective
When the objective is to prove a critical control resists realistic attack, a focused penetration test that demonstrates exploitability and defense effectiveness is the right fit. A broad scan lists potential weaknesses but does not prove impact, and skipping testing or reviewing only documents fails to answer the question posed.
- Which sequence correctly reflects the RMF activities that lead to an authorization to operate?
- Assess controls, then categorize, then select a baseline
- Monitor the system, then authorize, then write requirements
- Authorize the system, then implement controls, then categorize impact
- Implement controls, assess controls and produce the assessment report, then authorize based on residual risk
Correct answer: Implement controls, assess controls and produce the assessment report, then authorize based on residual risk
Controls are implemented, then assessed (producing the assessment report and findings), and the authorizing official then renders the authorization based on the resulting residual risk. The other sequences place authorization or assessment out of order, which would mean deciding to accept risk before evidence about the controls even exists.
- An ISSEP integrating a high-assurance cryptographic module into a federal system wants verifiable, independent evidence of the module's correctness. The most relevant source of that evidence is:
- The number of downloads the product has received
- A vendor blog post describing the module's features
- A FIPS 140 validation certificate from an accredited testing laboratory
- The integrator's verbal assurance that it works
Correct answer: A FIPS 140 validation certificate from an accredited testing laboratory
A FIPS 140 validation certificate, issued after testing by an accredited laboratory, provides independent verification that the cryptographic module meets defined security requirements. Vendor blogs, verbal assurances, and popularity metrics are not evidence of validated correctness and cannot substitute for accredited testing results.
- During implementation, the ISSEP verifies that the deployed configuration matches the approved hardened baseline. The most reliable way to detect unauthorized deviation is to:
- Review only the network diagram for changes
- Compare the running configuration against the controlled baseline using automated configuration assessment tooling
- Ask the system administrator whether anything was changed
- Assume the deployment matches because the installer reported success
Correct answer: Compare the running configuration against the controlled baseline using automated configuration assessment tooling
Automated comparison of the running configuration against the controlled baseline reliably detects deviations, including unintended or unauthorized changes. Relying on an administrator's memory, the installer's success message, or a static network diagram leaves gaps that automated configuration assessment closes.
- An assessment team is asked to evaluate controls they themselves implemented during development. The ISSEP objects primarily because this arrangement:
- Undermines assessor independence and introduces a conflict of interest that can bias results
- Requires the team to learn an unfamiliar system
- Will make the assessment finish too quickly to be billed
- Violates the requirement to categorize the system
Correct answer: Undermines assessor independence and introduces a conflict of interest that can bias results
Having developers assess their own controls undermines independence and creates a conflict of interest that can bias findings, which is exactly why independent verification and validation separates these roles. The concern is objectivity and credibility of evidence, not billing time, familiarity, or categorization.
- A system inherits several common controls from an enterprise service provider. During verification, the ISSEP should:
- Review the common control provider's assessment evidence and confirm the inherited controls actually satisfy this system's requirements
- Re-implement every inherited control locally regardless of need
- Exclude inherited controls from the assessment scope entirely
- Assume inherited controls need no verification because another team manages them
Correct answer: Review the common control provider's assessment evidence and confirm the inherited controls actually satisfy this system's requirements
Inherited (common) controls still require verification: the system owner reviews the provider's assessment evidence and confirms the controls meet the inheriting system's specific requirements. Assuming they are effective, redundantly re-implementing them, or excluding them from scope all create blind spots in the system's actual security posture.
- An ISSEP is selecting an assessment method for a control whose correctness depends on subtle internal logic and data flows that an external tester cannot observe. The most appropriate technique is:
- A physical inventory count of hardware
- Black-box testing only, with no internal knowledge
- A user satisfaction survey
- White-box (full-knowledge) testing using design documentation and source access to examine internal logic
Correct answer: White-box (full-knowledge) testing using design documentation and source access to examine internal logic
White-box (full-knowledge) testing, using design documentation and source access, lets the assessor examine the internal logic and data flows that determine the control's correctness. Black-box testing alone cannot reach this internal behavior, and surveys or hardware counts do not assess control logic at all.
- After a control assessment, the ISSEP assembles the security assessment report (SAR). Its primary role in the authorization process is to:
- Define the organization's enterprise risk tolerance
- Present the assessor's findings on control effectiveness and identified weaknesses so the authorizing official can make a risk-based decision
- Serve as the system's user training manual
- Establish the initial FIPS 199 impact categorization
Correct answer: Present the assessor's findings on control effectiveness and identified weaknesses so the authorizing official can make a risk-based decision
The security assessment report communicates the assessor's findings on control effectiveness and identified weaknesses, giving the authorizing official the evidence needed for a risk-based authorization decision. It is not a user manual, it does not set enterprise risk tolerance, and categorization occurs much earlier and elsewhere.
- An ISSEP is asked whether an interim or conditional authorization may be granted while specific weaknesses are remediated under a POA&M. The most accurate response is that the authorizing official:
- May grant a time-bound, conditional authorization that requires tracked remediation of identified weaknesses within a defined period
- Must always deny operation whenever any weakness remains open
- Has no authority to impose conditions on an authorization
- Can only grant authorization after every possible vulnerability is eliminated
Correct answer: May grant a time-bound, conditional authorization that requires tracked remediation of identified weaknesses within a defined period
An authorizing official may issue a time-bound, conditional authorization that permits operation while specific weaknesses are remediated on a tracked schedule via a POA&M. Since perfect security is unattainable, requiring zero weaknesses would make authorization impossible; the AO instead manages residual risk with conditions and timelines.
- During DevSecOps verification, a dependency scanner flags a vulnerable third-party library introduced in the latest build. The most appropriate pipeline behavior is to:
- Fail the build or block promotion until the component is updated, replaced, or the risk is formally accepted
- Ignore the finding because the library was added by a trusted developer
- Delete the scanner from the pipeline to prevent future alerts
- Automatically promote the build to production to maintain release velocity
Correct answer: Fail the build or block promotion until the component is updated, replaced, or the risk is formally accepted
Failing the build or blocking promotion until the vulnerable component is fixed, replaced, or its risk is formally accepted enforces the security gate that makes DevSecOps effective. Trusting the developer, promoting anyway for speed, or removing the scanner all defeat the purpose of automated verification in the pipeline.
- An ISSEP distinguishes a security assessment plan from the security assessment report. The key difference is that the plan:
- Is written by the authorizing official, while the report is written by end users
- Specifies how the assessment will be conducted before it occurs, while the report documents the findings after the assessment is complete
- Documents findings, while the report defines the assessment scope
- Replaces the system security plan, while the report replaces the POA&M
Correct answer: Specifies how the assessment will be conducted before it occurs, while the report documents the findings after the assessment is complete
The security assessment plan specifies how the assessment will be conducted (scope, procedures, schedule) before it occurs, while the security assessment report records the findings afterward. The reversed description is incorrect, and neither artifact is authored by end users nor replaces the SSP or POA&M.
- A modification to a previously verified system is delivered. To confirm the change did not break existing protections, the ISSEP directs:
- Regression security testing that re-exercises previously passing security test cases plus tests for the new change
- Re-categorization of the system from scratch
- Deletion of the original test cases to save storage
- A one-time check that the system powers on
Correct answer: Regression security testing that re-exercises previously passing security test cases plus tests for the new change
Regression security testing re-exercises the previously passing security test cases and adds tests for the new change, confirming nothing was broken or newly weakened. Re-categorizing, discarding the original test cases, or merely checking that the system powers on would not demonstrate that existing controls still function.
- An ISSEP is reconciling old certification-and-accreditation language with current NIST practice for a stakeholder briefing. Accreditation in the legacy model maps most closely to which modern step?
- The monitor step, in which controls are continuously assessed
- The categorize step, in which impact levels are assigned
- The implement step, in which controls are installed
- The authorization step, in which a senior official accepts residual risk and grants the authority to operate
Correct answer: The authorization step, in which a senior official accepts residual risk and grants the authority to operate
Accreditation in the legacy C&A model maps to the modern authorization step, where a senior official accepts residual risk and grants the authority to operate. Certification corresponds to assessment, not accreditation. Categorization, implementation, and monitoring are distinct RMF steps that do not equate to accreditation.
- A test plan must define entry criteria for security testing. The clearest reason to require a test readiness review before execution is to confirm that:
- All residual risk has been reduced to zero
- The test environment, data, procedures, and prerequisites are in place so that results will be valid and repeatable
- The system has already received its authorization to operate
- Marketing approval has been obtained for the release
Correct answer: The test environment, data, procedures, and prerequisites are in place so that results will be valid and repeatable
A test readiness review confirms the environment, data, procedures, and prerequisites are in place so that testing yields valid, repeatable results. Testing precedes authorization rather than following it, residual risk is rarely zero, and marketing approval is irrelevant to whether the test is technically ready.
- An ISSEP supporting verification of an AI-enabled security control wants to confirm the control cannot be manipulated into unsafe authorizations through crafted inputs. The most directly relevant technique is:
- Adversarial testing that deliberately attempts to bypass or trick the control to confirm its resilience against manipulation
- A spelling and grammar review of the system documentation
- Measuring the system's electrical power draw
- Counting the number of model parameters
Correct answer: Adversarial testing that deliberately attempts to bypass or trick the control to confirm its resilience against manipulation
Adversarial testing deliberately crafts inputs to bypass or trick the control, directly verifying its resilience against manipulation, which is essential for AI-driven enforcement. Documentation reviews, parameter counts, and power measurements tell the engineer nothing about whether the control can be defeated by malicious input.
- When the security test plan calls for assessing both whether the system meets its requirements and whether it satisfies stakeholder mission needs, the ISSEP is planning for:
- Validation only, because verification is automated and never planned
- Neither, because testing is unnecessary once controls are documented
- Verification only, because validation is a procurement task
- Both verification (against requirements) and validation (against stakeholder needs), since each answers a different question
Correct answer: Both verification (against requirements) and validation (against stakeholder needs), since each answers a different question
Assessing conformance to requirements (verification) and fitness for stakeholder mission needs (validation) requires planning for both, since they answer different questions: 'built right' versus 'right system.' Treating verification or validation as optional, or assuming documentation removes the need to test, would leave the security solution unproven.
- An ISSEP must verify a security requirement that states the system shall recover to a secure state within a defined time after a disruptive event. The most appropriate verification approach is to:
- Conduct a controlled test that induces the disruption and measures the actual recovery time against the requirement's threshold
- Ask the vendor whether recovery is fast
- Inspect the network diagram and assume recovery works
- Approve the requirement as met because the design mentions recovery
Correct answer: Conduct a controlled test that induces the disruption and measures the actual recovery time against the requirement's threshold
Inducing the disruption in a controlled test and measuring actual recovery time against the threshold directly verifies the timed-recovery requirement with evidence. Inspecting a diagram, accepting vendor assurances, or assuming the design implies the behavior provides no measured proof that the requirement is met.
- An ISSEP overseeing security test and evaluation insists that every test produce retained, reviewable artifacts (logs, screenshots, signed results) rather than a simple pass or fail mark. The primary engineering rationale is that:
- Screenshots are required by marketing for product brochures
- Objective evidence is required to substantiate assessment findings and support the authorizing official's risk decision and any later audit
- Artifacts are needed only to justify the size of the test team's budget
- Retained evidence eliminates the need to ever retest the system
Correct answer: Objective evidence is required to substantiate assessment findings and support the authorizing official's risk decision and any later audit
Retaining objective evidence such as logs, screenshots, and signed results substantiates the assessment findings, supports the authorizing official's risk decision, and withstands later audit. A bare pass/fail mark is not defensible on its own. Evidence retention is about traceable assurance, not budgets, avoiding retests, or marketing.
- Under NIST SP 800-88, an organization needs to sanitize solid-state drives (SSDs) that contained moderate-impact data so the media can be reused internally, while protecting against laboratory-level recovery attacks. Which sanitization category should the ISSEP specify?
- Destroy, because reuse is never permitted after any data is stored
- Purge, applying a method such as cryptographic erase or the device's secure-erase command
- Reformat, because formatting reliably removes all addressable data on flash media
- Clear, because a single logical overwrite is always sufficient for SSDs
Correct answer: Purge, applying a method such as cryptographic erase or the device's secure-erase command
Purge is correct: NIST SP 800-88 defines Purge as applying physical or logical techniques that render data recovery infeasible even using state-of-the-art laboratory methods, and for SSDs that includes cryptographic erase and built-in secure-erase/block-erase commands. Clear (logical overwrite) is unreliable on flash because wear-leveling can leave data in unmapped cells, so Clear alone does not meet a laboratory-resistant bar. Destroy would prevent the intended internal reuse, and reformatting is not a recognized sanitization technique.
- An ISSEP is finalizing the disposal plan for an encrypted storage array. The team wants the fastest method that still renders the data unrecoverable. The encryption was applied to the entire volume with strong, well-managed keys. Which approach best fits 'cryptographic erasure' as described in NIST SP 800-88?
- Sanitizing the media by securely destroying the encryption keys so the ciphertext cannot be decrypted
- Deleting the partition table and rebuilding the file system
- Degaussing the array to disrupt the magnetic domains of the drives
- Overwriting every logical block of the array three times before release
Correct answer: Sanitizing the media by securely destroying the encryption keys so the ciphertext cannot be decrypted
Destroying the encryption keys so the remaining ciphertext is unreadable is cryptographic erasure (CE). When data is encrypted at rest with strong keys, sanitizing or destroying the keys renders the underlying ciphertext computationally infeasible to recover, which is why CE is fast and effective and is treated as a Purge technique in NIST SP 800-88. Multi-pass overwriting is far slower; degaussing applies to magnetic media and does not address the key-destruction concept; deleting the partition table leaves the data intact.
- NIST SP 800-88 organizes media sanitization into the categories Clear, Purge, and Destroy. Which statement most accurately captures the relationship among them?
- Clear and Purge apply only to paper records, while Destroy applies only to electronic media
- Destroy is the only category that protects against simple keyboard-level recovery
- They are sequential phases that must always be performed in order on every device
- They represent increasing levels of assurance against data recovery, selected based on data confidentiality and whether the media will be reused
Correct answer: They represent increasing levels of assurance against data recovery, selected based on data confidentiality and whether the media will be reused
Clear, Purge, and Destroy represent increasing assurance against recovery, and the ISSEP selects the category based on data confidentiality and the disposition (reuse versus leaving the organization). Clear resists simple, non-invasive recovery; Purge resists laboratory attacks; Destroy renders the media unusable. They are not mandatory sequential phases, they do not split by paper versus electronic, and even Clear protects against keyboard-level recovery.
- A laptop hard drive held high-impact classified information and the media will leave organizational control as electronic waste. The drive cannot be reliably verified after a logical Purge attempt. Per NIST SP 800-88 decision logic, what should the ISSEP direct?
- Destroy the media through approved physical destruction such as shredding, disintegration, or incineration
- Purge with a single overwrite and release it to the recycler
- Clear the drive once, since the device is leaving the organization anyway
- Apply degaussing and then resell the drive on the secondary market
Correct answer: Destroy the media through approved physical destruction such as shredding, disintegration, or incineration
Physical destruction (shredding, disintegration, pulverizing, or incineration) is correct because the data was high-impact, the media is leaving organizational control, and Purge could not be verified. NIST SP 800-88's decision flow escalates to Destroy when verification of sanitization is not feasible and the confidentiality stakes are high. Clear is inadequate for high-impact data leaving control, and reselling a degaussed-then-functional drive is inconsistent with the destroy-and-do-not-reuse outcome required for the most sensitive media.
- NIST SP 800-88 recommends a verification step after sanitization. What is the primary security purpose of this verification?
- To confirm the warranty status of the media before disposal
- To provide evidence that the selected sanitization technique was applied successfully and achieved the intended result
- To replace the need for a documented chain of custody
- To re-categorize the information system to a lower impact level
Correct answer: To provide evidence that the selected sanitization technique was applied successfully and achieved the intended result
Verification provides evidence that sanitization was applied successfully and achieved the intended outcome, which is essential before media is reused, recycled, or released. NIST SP 800-88 pairs sanitization with verification (and a certificate or record) so the organization can demonstrate due diligence. Verification does not check warranties, does not change the system's categorization, and complements rather than replaces chain-of-custody documentation.
- An ISSEP is establishing an Information Security Continuous Monitoring (ISCM) program for a federal system under NIST SP 800-137. Which activity belongs specifically to the 'Establish' step of the ISCM process?
- Defining organizational risk tolerance that frames the overall monitoring strategy
- Responding to findings by mitigating, accepting, or transferring identified risks
- Determining metrics, monitoring and assessment frequencies, and the ISCM technical architecture
- Reviewing and updating the strategy to mature measurement capabilities over time
Correct answer: Determining metrics, monitoring and assessment frequencies, and the ISCM technical architecture
Determining metrics, status-monitoring frequencies, control-assessment frequencies, and the supporting technical architecture is the Establish step of NIST SP 800-137's six-step process. Setting risk tolerance belongs to the earlier Define step; responding to findings is the Respond step; and maturing the program is the Review-and-Update step. The full sequence is Define, Establish, Implement, Analyze/Report, Respond, and Review/Update.
- Per NIST SP 800-137, what determines how frequently a given security control or asset is monitored within an ISCM program?
- The volatility of the control and the risk it addresses, aligned to organizational risk tolerance
- A fixed annual schedule applied uniformly to all controls regardless of risk
- Whichever controls are easiest to scan with existing tools
- The vendor's recommended maintenance interval for each product
Correct answer: The volatility of the control and the risk it addresses, aligned to organizational risk tolerance
Monitoring frequency is driven by the volatility of the control and the level of risk it addresses, calibrated to organizational risk tolerance. NIST SP 800-137 directs more volatile or higher-risk items to be assessed more often, rather than applying a single uniform interval. Vendor maintenance schedules and tool convenience are not the governing criteria for ISCM frequency decisions.
- An ISSEP is differentiating continuous monitoring (per NIST SP 800-137) from a point-in-time security control assessment. Which statement best captures the distinguishing purpose of continuous monitoring in secure operations?
- It produces the system's initial security categorization before deployment
- It is a one-time penetration test performed just prior to the authorization decision
- It maintains ongoing awareness of security state, vulnerabilities, and threats to keep risk and authorization decisions current
- It eliminates the need for a system security plan during operations
Correct answer: It maintains ongoing awareness of security state, vulnerabilities, and threats to keep risk and authorization decisions current
Continuous monitoring maintains ongoing awareness of the security state, vulnerabilities, and threats so that risk decisions and the authorization remain current throughout operations. Unlike a one-time assessment or penetration test, it provides sustained, near-real-time visibility that supports ongoing authorization. Categorization happens earlier in the lifecycle, and the system security plan is maintained, not eliminated.
- A change request proposes adding a new external interface to an operational system. Following disciplined change management, when should the security impact analysis be completed?
- Before the change is approved and implemented, so its effect on controls and risk informs the decision
- Never, because adding interfaces is a routine maintenance task
- Only if the help desk later reports a related incident
- After the change is deployed to production, as part of the next audit
Correct answer: Before the change is approved and implemented, so its effect on controls and risk informs the decision
The security impact analysis must be completed before the change is approved and implemented, so its effect on controls and residual risk informs the approval decision and any needed reassessment. Performing the analysis after deployment defeats its purpose of catching adverse security effects in advance. Adding an external interface expands the attack surface and is precisely the kind of change that warrants up-front analysis, not deferral.
- Within a change management process, what is the primary security reason for placing approved configuration baselines under formal configuration control during operations?
- To eliminate the need for continuous monitoring of the system
- To freeze the system so that no security patches are ever applied
- To allow any administrator to apply undocumented hotfixes quickly
- To establish an authoritative, approved reference so unauthorized deviations can be detected and changes can be assessed and traced
Correct answer: To establish an authoritative, approved reference so unauthorized deviations can be detected and changes can be assessed and traced
Configuration control establishes an authoritative, approved baseline that serves as the reference for detecting unauthorized deviations and for assessing and tracing every proposed change. This underpins both change management and drift detection. It does not authorize undocumented hotfixes, does not replace continuous monitoring, and does not prevent patching; rather, patches flow through the controlled change process.
- During the containment phase of incident response in an operational system, an ISSEP advises the response team on a host that may be actively exfiltrating data. Which action best reflects the containment objective while preserving the ability to investigate?
- Take no action until the full root-cause analysis is complete
- Isolate the affected host from the network to stop spread while preserving volatile data and evidence for analysis
- Immediately wipe and rebuild the host to restore service as fast as possible
- Disable all logging on the host to reduce noise during the response
Correct answer: Isolate the affected host from the network to stop spread while preserving volatile data and evidence for analysis
Isolating the affected host to halt spread and exfiltration while preserving volatile data and evidence is the correct containment action; it limits ongoing loss without destroying the information needed for eradication and analysis. Immediately wiping and rebuilding destroys forensic evidence and may not address the root cause. Disabling logging removes critical evidence, and inaction allows continued harm during an active incident.
- An ISSEP is reviewing the incident response lifecycle (consistent with NIST guidance) for an operational system. Which sequence correctly orders the core phases?
- Preparation; detection and analysis; containment, eradication, and recovery; post-incident activity
- Recovery, detection, preparation, eradication, containment
- Detection, authorization, categorization, disposal, monitoring
- Containment, preparation, detection, recovery, lessons learned
Correct answer: Preparation; detection and analysis; containment, eradication, and recovery; post-incident activity
The correct order is preparation; detection and analysis; containment, eradication, and recovery; and post-incident activity (lessons learned), reflecting the NIST incident response lifecycle. Preparation must precede detection, and lessons learned close the loop to feed back into preparation. The other sequences scramble the phases or mix in unrelated RMF and disposal activities that are not part of the incident response lifecycle.
- An ISSEP is decommissioning a system that other operational systems depend on for several inherited common controls and a shared authentication service. To support secure decommissioning, what must be addressed beyond sanitizing the media?
- Immediately deleting all audit logs to reduce storage costs
- Only the physical removal of the server racks from the data center
- Leaving the system powered on indefinitely so dependents are not disrupted
- Identifying dependent systems and coordinating replacement of inherited controls and shared services before connectivity is removed
Correct answer: Identifying dependent systems and coordinating replacement of inherited controls and shared services before connectivity is removed
Secure decommissioning requires identifying systems that depend on this one and coordinating replacement of the inherited common controls and shared services before connectivity is severed, so dependents do not silently lose protections. Disposal is more than removing hardware. Deleting audit logs can violate retention and forensic obligations, and leaving the system running indefinitely defeats the purpose of decommissioning while extending the attack surface.
- When planning secure decommissioning of a cloud-hosted system, an ISSEP recognizes that data may persist across replicas, backups, and snapshots managed by the provider. What is the most appropriate engineering response?
- Assume the provider automatically sanitizes all copies the moment the instance is deleted
- Specify and verify sanitization or cryptographic erasure across all data copies, including backups and snapshots, via contractual and technical controls
- Delete only the running instance, since backups are not the consumer's responsibility
- Rely on instance termination alone because cloud media cannot retain residual data
Correct answer: Specify and verify sanitization or cryptographic erasure across all data copies, including backups and snapshots, via contractual and technical controls
The ISSEP should specify and verify sanitization or cryptographic erasure across all data copies, including replicas, backups, and snapshots, using both contractual and technical controls. In shared-responsibility cloud environments, deleting only the running instance leaves recoverable data in backups and snapshots. Assuming the provider silently sanitizes every copy, or that cloud media cannot retain data, is unfounded and creates data remanence risk.
- An organization performs media sanitization in-house and also uses a third-party disposal vendor for bulk destruction. Which control most directly maintains accountability that sensitive media was actually sanitized or destroyed?
- A verbal assurance from the vendor's account manager
- A marketing report on the volume of e-waste recycled
- A documented chain of custody plus sanitization/destruction certificates tied to each asset
- The vendor's general privacy policy posted on its website
Correct answer: A documented chain of custody plus sanitization/destruction certificates tied to each asset
A documented chain of custody combined with sanitization or destruction certificates tied to each specific asset maintains accountability that sensitive media was handled and sanitized or destroyed as required. This evidence supports audits and demonstrates due diligence when third parties are involved. Marketing volume reports, verbal assurances, and a generic website privacy policy provide no per-asset accountability for sanitization.
- A continuous monitoring program for a high-impact system is producing thousands of low-priority scan alerts that overwhelm analysts, causing real indicators to be missed. Applying NIST SP 800-137 principles, what is the most effective improvement?
- Increase the scan frequency uniformly across every asset to capture more data
- Stop scanning entirely to reduce the alert volume
- Forward all raw alerts to the authorizing official for individual decisions
- Tune metrics, frequencies, and thresholds to organizational risk so monitoring data drives prioritized, actionable response
Correct answer: Tune metrics, frequencies, and thresholds to organizational risk so monitoring data drives prioritized, actionable response
Tuning metrics, monitoring frequencies, and alert thresholds to organizational risk so the data is prioritized and actionable is the correct ISCM improvement; NIST SP 800-137 emphasizes that monitoring must yield meaningful, decision-supporting information rather than undifferentiated noise. Halting scanning sacrifices visibility, flooding the authorizing official with raw alerts is unworkable, and uniformly increasing frequency worsens the overload instead of focusing effort where risk is greatest.
- An ISSEP is selecting a media sanitization technique and weighs reusing the media internally against the cost of new hardware. According to NIST SP 800-88, which two factors most directly drive the choice among Clear, Purge, and Destroy?
- The purchase price of the media and the vendor's brand reputation
- The age of the system and the number of users who had accounts
- The data center's power capacity and the available rack space
- The confidentiality (impact) level of the data and the intended disposition of the media (reuse versus leaving organizational control)
Correct answer: The confidentiality (impact) level of the data and the intended disposition of the media (reuse versus leaving organizational control)
The data's confidentiality/impact level and the media's intended disposition (whether it will be reused internally or leave organizational control) are the two primary factors NIST SP 800-88 uses to select Clear, Purge, or Destroy. Higher confidentiality and media leaving control push toward Purge or Destroy, while lower-impact media kept internally may justify Clear. Purchase price, brand, system age, and facility constraints are not the governing sanitization-decision factors.