Select Two (Multi-Select) Questions

The SSP and POA&M are the same document.

Why it fails: Conflating these documents ignores their distinct roles in the risk management framework, where the System Security Plan details the implemented security controls of a system, whereas the Plan of Action and Milestones schedules the remediation of identified security deficiencies. This confusion often arises because both are mandatory artifacts produced during the security authorisation lifecycle and are reviewed in tandem by auditors. Treating them as a single document would be correct only if an organisation maintained a unified compliance ledger that dynamically merged its baseline security configuration with its outstanding remediation tracking.

The POA&M replaces the need for an SSP.

Why it fails: A System Security Plan documents the complete security posture and implemented controls of an information system, whereas a Plan of Action and Milestones specifically tracks known vulnerabilities and remediation schedules. Treating the remediation roadmap as a total substitution for the baseline security documentation fails because tracking outstanding deficiencies cannot describe the structural architecture, boundaries, and active safeguards required for continuous authorisation. This statement appears plausible because both artefacts are core components of risk management frameworks used during security assessments; a remediation tracking document would be the correct choice solely when managing corrective actions for identified control deficiencies after the baseline architecture has already been fully established and documented elsewhere.

The SSP only needs to be updated when the system is decommissioned.

Why it fails: System security documentation must remain a living record that continuously mirrors the current operational baseline and security posture of an information system, meaning that waiting until decommissioning would leave security controls completely unmanaged throughout the operational lifecycle. This misconception arises because professionals often view baseline documentation as a static archival artifact rather than an agile repository. Such an approach would only be valid if the system operated in a completely isolated, immutable state from deployment to retirement with zero configuration changes, software patches, or emerging threat adjustments.

Update the disaster recovery plan to remove the system.

Why it fails: While updating the disaster recovery plan is good practice, it is not essential for secure disposal of the system itself. The focus of secure decommissioning is on data remanence and access removal. Removing the system from the DR plan is part of lifecycle documentation but does not directly ensure secure disposal.

Conduct a vulnerability scan of the system before decommissioning.

Why it fails: A vulnerability scan is not essential for secure disposal; it is more relevant for systems in operation. Scanning a system that is being decommissioned does not address data remanence or access removal. It may be part of a broader assessment, but it is not a core action for secure decommissioning.

Back up all data to a long-term archive for potential future use.

Why it fails: Backing up data for future use contradicts the goal of secure disposal, which is to ensure data is irretrievably destroyed if no longer needed. If data must be retained, it should be done in accordance with retention policies, but the scenario implies disposal. Archiving all data would increase risk and is not essential for secure decommissioning.

Quarterly hardware refresh

Why it fails: Hardware refresh cycles are periodic procurement events, not a monitoring control; ConMon requires continuous automated data collection against a defined baseline. It is tempting because asset lifecycle management supports security generally, and refresh planning would be relevant to a hardware maintenance or capacity programme, but it produces no ongoing visibility into control effectiveness.

Manual annual log review

Why it fails: Annual manual review is point-in-time and human-driven, whereas ConMon demands automated, near-real-time collection and analysis of security state. It is tempting because log review genuinely supports detection, and an annual audit-style review would suit a periodic compliance assessment, but the yearly cadence and manual effort defeat continuous oversight.

Replace the entire system to eliminate the risk.

Why it fails: Replacing the entire system represents a disproportionate response that fails to address the requirement of managing residual risk within an existing Risk Management Framework. While system replacement serves as a valid risk avoidance strategy when legacy infrastructure reaches an unpatchable end-of-life state or incurs prohibitive maintenance costs, it constitutes a complete lifecycle termination rather than a risk treatment activity. Organisations should only pursue this drastic measure when the inherent risk exceeds the risk appetite and no combination of technical or administrative controls can mitigate the threat.

Ignore the risk if it is below a certain threshold.

Why it fails: Ignoring residual risk without formal authorisation fails the Risk Management Framework requirement for explicit acceptance by an Authorising Official. While organisations often establish a de minimis threshold to avoid wasting resources on negligible threats, this practice serves as a prioritisation filter for risk assessment rather than a final treatment strategy. This approach is tempting because it streamlines administrative overhead for minor vulnerabilities, yet it lacks the documented accountability and formal sign-off necessary to satisfy the mandatory risk treatment obligations defined within the RMF process.

Automate the assessment of the risk indefinitely.

Why it fails: Automating risk assessment provides continuous monitoring of security posture rather than addressing the residual risk itself, which requires formal acceptance or mitigation strategies. While this approach is valuable for maintaining visibility into dynamic environments or verifying the efficacy of controls within Microsoft Entra ID, it functions as a detective mechanism rather than a risk treatment decision. Organisations must formally acknowledge and document the remaining threat exposure through risk acceptance or transfer, as automation merely reports on the status of controls without resolving the underlying vulnerability.

Replace all legacy PLCs with new models that support patching.

Why it fails: While replacement is a long-term solution, it is not a compensating control and may be cost-prohibitive or disruptive to operations. The question asks for compensating controls to reduce risk in the current state. Replacement is a risk avoidance strategy, not a compensating control, and may take years to implement.

Deploy host-based antivirus software directly on the PLCs.

Why it fails: Legacy PLCs typically run real-time operating systems that do not support host-based antivirus software. Installing such software could disrupt control processes and is often technically infeasible. Antivirus is not a viable compensating control for PLCs; instead, network-level protections are more appropriate.

Require all operators to use multi-factor authentication (MFA) when logging into the PLCs.

Why it fails: Legacy PLCs often lack support for MFA and may not have user authentication at all. Even if MFA could be added, it does not address network-based attacks or physical tampering. MFA is a good practice for human-machine interfaces (HMIs) but is not the most effective compensating control for the PLCs themselves.

Archive all data to a public cloud bucket.

Why it fails: Placing sensitive decommissioned data into a public cloud bucket fails because public accessibility controls leave sensitive records exposed to unauthorised internet traffic, violating data confidentiality requirements. Conversely, cloud object storage is designed for scalable, cost-effective off-site data retention and disaster recovery. This approach would be the correct choice when publishing non-sensitive, public-facing datasets or media assets that require global accessibility without confidentiality constraints.

Format the hard drive as a quick process.

Why it fails: Quick formatting merely reindexes the file allocation table and marks storage sectors as available without overwriting the actual binary data, leaving sensitive residual information recoverable using standard data recovery tools. This superficial method is designed for rapidly preparing operational media for immediate reuse by clearing pointers rather than destroying content, which would be appropriate only when redeploying the hardware within the same secure environment where data confidentiality has not been compromised.

Migrate the directory user attributes to the new identity system and then leave the legacy database intact for historical reference.

Why it fails: Leaving the legacy database intact after migration retains personal data beyond its authorized lifecycle and expands the attack surface. Historical reference needs can be met with sanitized extracts or archived records that comply with retention policy, not a live database copy. This action does not dispose of the data and conflicts with the decommissioning objective.

Archive the root CA private keys in an offline vault so they can be used to re-sign certificates if validation issues arise later.

Why it fails: Retaining root CA private keys after decommissioning creates a persistent forgery risk and violates the principle of eliminating unnecessary key material. If validation issues arise, the archived public certificates and revocation information are sufficient; the private keys are not needed. Keeping them in a vault extends the attack surface beyond the system's operational life.

Delete the directory database by dropping all tables and removing the database files from the storage array without further sanitization.

Why it fails: Dropping tables and deleting files does not sanitize the underlying storage, so user attributes could be recovered with forensic tools. The directory contains personal data that requires proper media sanitization or cryptographic erase. This approach leaves residual data and fails the disposal requirement for the user attributes.

Reviewing the manufacturer's specifications for the badge reader hardware.

Why it fails: Reviewing manufacturer specifications provides information about the capabilities of the hardware but does not verify that it is implemented correctly in the facility. Specifications do not confirm that the system is configured to enforce access restrictions or that it operates as intended in the operational environment. This activity is a documentation review, not a verification of implementation. Thus, it does not provide evidence that the physical access control is functioning properly.

Interviewing employees about their perception of the facility's security.

Why it fails: Interviewing employees about their perception of security provides subjective information and does not verify the implementation of physical access controls. Employee opinions may be influenced by various factors and do not constitute objective evidence that controls are functioning as intended. While interviews can be part of an assessment, they are not a reliable verification activity for physical access control mechanisms. Therefore, this is not an appropriate verification activity in this context.

Reviewing the access control policy to ensure it defines authorized personnel.

Why it fails: Reviewing the access control policy verifies that documentation exists and defines authorized personnel, but it does not confirm that the physical access control mechanisms are actually implemented and functioning. Policy review is a documentation check, not a verification of implementation. While important for governance, it does not provide evidence that controls such as badge readers or locks are operating as intended. Therefore, it is not the best activity for verifying physical access control implementation.

Periodic reauthorization of every subsystem by the Authorizing Official on a fixed annual schedule.

Why it fails: Fixed annual reauthorization is a point-in-time activity, not continuous monitoring. It does not provide ongoing visibility and can leave an entire year of drift undetected. Continuous monitoring is intended to reduce reliance on periodic reviews by supplying near-real-time awareness, so this option works against the stated goal rather than supporting it.

Replacing the system's security assessment with an annual penetration test performed by an external team.

Why it fails: A penetration test is a point-in-time adversarial exercise, not a continuous monitoring mechanism. It cannot detect configuration drift, new vulnerabilities, or control degradation that occurs between tests. While valuable, it complements rather than replaces the ongoing collection, analysis, and escalation activities that continuous monitoring requires.

Full re-testing of every security control in the baseline at the same frequency, regardless of risk or volatility.

Why it fails: Uniformly re-testing all controls at one frequency wastes resources on stable, low-risk controls while under-monitoring volatile, high-risk ones. Effective continuous monitoring uses risk-based frequencies and automation. This option also conflates exhaustive testing with continuous monitoring, which emphasizes ongoing data collection and analysis rather than repeating full assessments.

Rely on discretionary access control lists managed by each domain to control cross-domain access.

Why it fails: Discretionary access control allows users to grant access at their discretion, which can lead to unintended information flow and does not provide the rigid, policy-driven separation required for multiple independent levels of security. It cannot guarantee non-interference because a user in one domain could inadvertently or maliciously share data with another.

Use a single shared operating system instance with role-based access control to separate domains.

Why it fails: A single shared operating system instance cannot provide the strong isolation required for multiple independent levels of security because a vulnerability in the shared OS could compromise all domains. Role-based access control is a policy mechanism, not an isolation mechanism, and does not prevent covert channels or interference between domains.

Use a shared memory segment for inter-domain communication to improve performance and reduce complexity.

Why it fails: Shared memory creates a covert channel and a direct path for information flow between domains, violating isolation and non-interference. Even with access controls, shared memory can allow one domain to influence another through timing or storage channels, so it is not an appropriate technique for multiple independent levels of security.

Calculating the annualized loss expectancy for every asset in the enterprise enclave

Why it fails: Quantitative loss expectancy calculations can inform risk analysis but are not an essential component of every system-level assessment, and applying them to every enterprise asset is disproportionate. The assessment must identify threats, vulnerabilities, and impacts; ALE is one optional technique, not a required element for this cross-domain scenario.

Selecting the specific commercial product that will implement the cross-domain guard

Why it fails: Product selection is an acquisition and engineering decision that follows the risk assessment, not a component of it. The assessment identifies threats, vulnerabilities, and impacts so decision-makers can choose appropriate solutions. Including product selection in the assessment confuses analysis with procurement and could bias the assessment toward a predetermined vendor.

Obtaining the Authorizing Official's signature on the Authority to Operate before beginning analysis

Why it fails: The Authority to Operate is the authorization decision that follows assessment and risk determination; it cannot precede the analysis. Requiring a signature before beginning would invert the RMF sequence and leave the Authorizing Official without the evidence needed to decide. This is a sequencing error, not an essential assessment activity.

Notify all users of the change and obtain their written acknowledgment before implementing the change.

Why it fails: User notification and acknowledgment may be part of organizational change procedures, but they are not the activities that maintain the authorization. The authorization is maintained through analysis and documentation updates. User acknowledgment does not assess security impact or update the authorization package, so it does not satisfy the requirement.

Submit the change to the Change Advisory Board and wait for a unanimous vote before proceeding.

Why it fails: The Change Advisory Board plays a role in reviewing and prioritizing changes, but a unanimous vote is not a requirement for maintaining an authorization. The security-relevant activities are the impact analysis and documentation updates. Relying on a CAB vote alone would not address the security posture or the accuracy of the authorization package.

Reauthorize the system from scratch by conducting a full security assessment of all controls regardless of the change scope.

Why it fails: A full reauthorization and complete assessment of every control is not required for every security-relevant change. Continuous authorization relies on targeted analysis and assessment proportional to the change. Conducting a full assessment each time would be inefficient and is not the prescribed approach. The focus should be on the controls affected by the change.

The average keyboard typing speed of operators in each participating nation.

Why it fails: Operator typing speed is an ergonomic metric with no direct relationship to system security risk. It does not influence the likelihood or impact of a security event in a coalition environment. Risk assessments focus on threats, vulnerabilities, and consequences, not on individual performance metrics. This option is clearly irrelevant and serves as a distractor.

The physical color scheme and branding of the user interface used by each coalition partner.

Why it fails: User interface aesthetics and branding are usability considerations, not security risk factors. They do not affect confidentiality, integrity, or availability of shared data in a coalition environment. While consistency can aid training, it has no bearing on the legal, technical, or operational risks that an ISSEP must evaluate. This option is a distractor based on superficial customization.

The number of languages into which the system's help documentation has been translated.

Why it fails: Documentation translation affects usability and training, not the security risk posture of the shared system. It does not change threat exposure, vulnerability likelihood, or impact. While multilingual support may be operationally desirable, it is not a primary risk factor for a coalition data-sharing assessment. This option distracts from the legal, procedural, and technical risks that matter.

Using only qualitative risk ratings so that numeric precision cannot be challenged during oversight reviews.

Why it fails: Qualitative ratings are useful, but restricting the process to them removes the ability to express likelihood and impact quantitatively where data supports it. Oversight challenges are addressed through documented assumptions and methodology, not by avoiding quantification. A mature process selects the method appropriate to the decision and available data, so a blanket restriction would weaken rather than strengthen defensibility.

Requiring every risk to be mitigated to zero before the system receives an Authority to Operate.

Why it fails: Zero residual risk is neither achievable nor required; authorization permits operation with documented residual risk within tolerance. Demanding elimination of all risk would halt the program and contradicts the purpose of risk management, which is informed acceptance rather than avoidance. This option misstates the goal and would make the process unworkable rather than repeatable.

Delegating all risk decisions to the system owner to accelerate the accreditation timeline.

Why it fails: The system owner implements and operates controls but does not hold final risk acceptance authority for accreditation. Delegating all decisions to that role removes the Authorizing Official from the accountability chain and undermines the separation of duties that makes risk decisions defensible. Acceleration of schedule is not a valid reason to restructure authority in a way that conflicts with the authorization framework.

AC-2 Account Management

Why it fails: AC-2 focuses on managing system accounts, including creation, enabling, modification, disabling, and removal. While important for access control, it does not directly protect data at rest. Unauthorized access to data at rest could occur through compromised accounts, but AC-2 alone does not provide the cryptographic protection needed. It is a complementary control, but not the most appropriate for addressing data-at-rest confidentiality and integrity.

CM-6 Configuration Settings

Why it fails: CM-6 requires establishing and enforcing secure configuration settings for IT products. While misconfigurations can lead to unauthorized access, CM-6 is a broad control that covers many aspects of system hardening. It is not specifically focused on protecting data at rest. In contrast, SC-28 and SC-13 are directly aimed at cryptographic protection of stored data. Therefore, CM-6 is less appropriate for the specific risk of unauthorized access to data at rest.

AU-2 Event Logging

Why it fails: AU-2 defines the events that need to be logged to support auditing and monitoring. While logging is critical for detecting unauthorized access attempts, it is a detective control, not a preventive one. It does not protect data at rest from being accessed or modified. The question asks for controls to address the risk of unauthorized access, implying preventive measures. AU-2 is important but not the most appropriate for directly protecting data at rest.

The tranquility principle: security labels may not be changed while the system is processing data.

Why it fails: The tranquility principle is a supporting assumption of Bell-LaPadula that labels remain fixed during processing so that access decisions stay consistent. It is not one of the two core access rules that directly prevent disclosure. While important for stable enforcement, the question asks for the rules that prevent unauthorized disclosure, and tranquility is a constraint on label changes rather than an access rule governing read or write operations.

The weak tranquility principle: subjects may change their security level only after re-authentication.

Why it fails: Weak tranquility allows labels to change in a controlled manner without violating the model's intent, but it is not a Bell-LaPadula access rule. Re-authentication is an authentication concern, not a confidentiality flow rule. The scenario asks which rules prevent unauthorized disclosure, and weak tranquility does not by itself stop a subject from reading up or writing down, so it is not one of the required rules.

The Biba integrity property: a subject may not read an object at a lower integrity level.

Why it fails: The Biba model addresses integrity, not confidentiality, and its rules are designed to prevent corruption of high-integrity data. Applying a Biba rule here would not prevent unauthorized disclosure of classified information and would instead impose integrity constraints unrelated to the confidentiality goal. The scenario explicitly concerns preventing disclosure under Bell-LaPadula, so a Biba property is the wrong model for this requirement.

Develop a configuration management plan to track changes to the system throughout its lifecycle.

Why it fails: A configuration management plan is important for maintaining system integrity, but it does not directly derive security requirements for incident protection, detection, and response. It is a supporting process that ensures changes are controlled, not a requirements elicitation activity.

Perform a business impact analysis to determine the criticality of system assets and processes.

Why it fails: A business impact analysis focuses on the consequences of disruption to business functions, not on deriving technical security requirements for incident protection, detection, and response. While it informs risk management, it does not directly yield the security requirements needed for this engineering task.

Create a continuous monitoring strategy to track the effectiveness of security controls over time.

Why it fails: A continuous monitoring strategy is used after controls are implemented to assess their ongoing effectiveness. It does not derive the initial security requirements for protection, detection, and response. While related to response, it is an operational activity rather than a requirements definition activity.

Open design

Why it fails: Open design means that the security of the system should not depend on the secrecy of its design, only on the secrecy of keys. While a good principle, it is not specific to integrating COTS and GOTS components in a high-assurance system. The critical principles are those that enforce access control and trusted communication, such as reference monitor and trusted path. Open design is more about avoiding security through obscurity.

Economy of mechanism

Why it fails: Economy of mechanism advocates for simple, small security mechanisms to reduce the chance of errors. While important, it is not the most critical principle when integrating multiple components in a high-assurance system. The integration challenge primarily requires ensuring that all access is mediated and that secure communication paths exist. Economy of mechanism is a general design principle, but less directly relevant to the integration of COTS and GOTS.

Modularity

Why it fails: Modularity promotes ease of maintenance and replacement of components, but it is not a primary security principle for high-assurance integration. While it can aid in isolating faults, it does not directly ensure the security objectives of confidentiality and integrity in a top secret system. Modularity is a design quality, not a security assurance requirement. The most critical principles are those that enforce access control and trusted communication.

Manual source code review against secure coding standards

Why it fails: Manual code review inspects source text without executing the program. It is a static technique that can find injection flaws, hardcoded credentials, and unsafe API use. However, it cannot observe runtime behavior, race conditions, or configuration interactions. Because the question asks for dynamic techniques, reviewing code by reading it fails the criterion even though it remains valuable for finding certain defect classes.

Static application security testing (SAST) scanning

Why it fails: SAST tools analyze source, bytecode, or binaries without running the application. They build models of data flow and flag suspicious patterns. This is definitionally static analysis, so it does not belong in the dynamic category. It complements dynamic testing by covering code paths that tests may not reach, but it cannot demonstrate actual runtime behavior of the command-and-control system under load or attack.

Software composition analysis of third-party libraries

Why it fails: Software composition analysis inventories dependencies and matches them against known vulnerability databases. It examines manifests and package metadata rather than executing the system, making it a static supply-chain technique. It answers what components are present and which CVEs apply, not how the running system behaves. Therefore it is not a dynamic verification technique for the deployed command-and-control system.

Review the certificate practice statement to confirm it documents the issuance and revocation procedures.

Why it fails: The certificate practice statement describes intended procedures but does not demonstrate that they are followed. Documentation can be accurate while the technical controls are misconfigured or bypassed. Reviewing it is useful for understanding requirements, yet it cannot provide direct evidence that issuance policy enforcement and revocation checking actually work in the deployed environment.

Verify that the CA server's clock is synchronized with an authoritative time source.

Why it fails: Accurate time is important for certificate validity windows and revocation timestamps, but clock synchronization alone does not prove that issuance policy is enforced or that relying parties check revocation. It is a supporting infrastructure check rather than direct evidence of the two controls under validation, so it does not satisfy the verification objective by itself.

Confirm that the root certificate is stored in the organization's configuration management database with a current owner.

Why it fails: Asset tracking of the root certificate supports governance and accountability but says nothing about whether issuance policy is enforced or revocation is honored. A well-tracked root can still front a CA that issues improper certificates or publishes unusable revocation data. This activity verifies inventory hygiene, not the operational effectiveness of issuance and revocation controls.