Hard Difficulty Questions

Check if logs are printed to the console.

Why it fails: Console output is transient and typically lost on restart, so it cannot satisfy NIST SP 800-92 requirements for retained, reviewable records. Console logging is tempting for quick interactive debugging, but the standard expects centralised, protected log storage with integrity and retention controls.

Confirm that the logging level is set to 'DEBUG'.

Why it fails: Setting the logging level to 'DEBUG' violates production compliance guidelines under NIST SP 800-92 because it generates an excessive volume of granular diagnostic data, capturing sensitive internal application states, user credentials, and PII that should never be written to permanent audit logs. This option is tempting because developers routinely rely on 'DEBUG' mode during troubleshooting to trace execution paths and inspect variable states, meaning this configuration would be appropriate exclusively within isolated pre-production or sandbox environments during active software debugging phases.

Verify that all logs are stored in a database.

Why it fails: A database is merely one possible storage medium; NIST SP 800-92 mandates centralised collection, retention, integrity and access controls, not a specific backend. Databases are tempting because they offer querying, yet logs written to flat files with those controls are equally compliant.

Deny the change because audit logging modifications always require full board approval.

Why it fails: A blanket denial ignores the emergency change path that the process provides for urgent operational needs. Refusing without evaluating compensating controls or the actual risk leaves the peak period unaddressed and may force an uncontrolled workaround. The correct response is to use the emergency mechanism with proper documentation and follow-up, not to treat all logging changes as categorically prohibited.

Reduce log volume by filtering events at the collection tier instead of changing the source configuration.

Why it fails: Filtering at collection can reduce stored volume, but it may discard events needed for investigation and does not address the source configuration if that is what generates the excess. It also constitutes a change to the monitoring pipeline that itself requires authorization. Without an approved emergency change record, this alternative merely shifts the same governance problem to a different component.

Implement the change immediately and document it after the peak period ends.

Why it fails: Implementing without any prior authorization or recorded security impact removes accountability and may violate the system's authorization boundary. Even under emergency procedures, the change should be authorized by a designated official and its security impact captured at the time. Deferring all documentation until later creates a gap in the audit trail and makes it harder to justify or reverse the change.

Equal Error Rate (EER)

Why it fails: EER is synonymous with CER and represents the threshold where false acceptance and false rejection rates are equal. It is a comparative metric, not a direct measure of false acceptance risk. The system owner needs the specific probability of accepting an impostor, which is given by FAR, not by the balanced EER.

Crossover Error Rate (CER)

Why it fails: CER is the point where FAR equals FRR and is used to compare biometric system accuracy. It does not isolate the risk of false acceptance; it balances both error types. While useful for selecting a biometric modality, CER does not directly answer the system owner's question about the likelihood of an unauthorized user being accepted.

False Rejection Rate (FRR)

Why it fails: FRR measures the probability that a legitimate user is incorrectly rejected. It relates to availability and user inconvenience, not the risk of an unauthorized user being accepted. While important for usability, it does not quantify the security exposure from false acceptance. The system owner's concern about unauthorized access requires a different metric.

To simplify the audit process

Why it fails: Streamlining compliance reviews by reducing documentation overhead is the primary purpose of audit simplification, making it an attractive goal when preparing for routine ISO 27001 or SOC 2 assessments. Such an approach would be appropriate when designing administrative controls for low-risk, internal-only applications where administrative efficiency outweighs the threat of malicious insider tampering. However, in a regulated environment subject to strict frameworks like PCI DSS, regulatory compliance mandates preventing unilateral tampering rather than merely easing auditor workflows. Therefore, separating build and deploy responsibilities is strictly enforced to provide cryptographic non-repudiation and prevent unauthorized code modifications, rendering administrative convenience irrelevant to the core security objective.

To reduce operational costs

Why it fails: Cost reduction targets administrative overhead by consolidating personnel responsibilities, whereas regulatory compliance in security-sensitive environments mandates independent verification to prevent malicious code injection. Consolidating build and deploy roles would indeed minimise headcount expenses and streamline workflow velocity, making it an attractive strategy for commercial budgeting exercises. However, balancing financial efficiency directly violates segregation controls required to mitigate insider threats, rendering economic optimisation irrelevant when evaluating risk management frameworks governing critical infrastructure deployments.

To increase server performance

Why it fails: Separation of duties between build and deploy roles addresses governance and accountability risks, not hardware throughput or resource allocation. The temptation to link administrative controls with server performance stems from high-availability architectures where workload distribution and process isolation are managed through distinct operational tiers. In scenarios focused on optimising compute capacity or mitigating resource starvation during heavy compilation tasks, load balancing and horizontal scaling would be the correct technical choices rather than governance frameworks.

Perform an audit of the HSM's internal log files.

Why it fails: Auditing internal log files monitors logical events, software activities, and administrative access trails, meaning it fails to address the physical security posture required to confirm that the hardware security module has not been tampered with or physically compromised. Analysing log files is tempting because it forms a critical component of regular compliance and cryptographic governance reviews, and it would be the correct choice when investigating unauthorised logical access attempts, tracking administrator command histories, or verifying procedural compliance during routine operational audits.

Verify the HSM firmware version against the manufacturer's website.

Why it fails: Checking firmware versions confirms software integrity and patch levels against known vulnerabilities, but it does not evaluate physical tampering, enclosure breach detection, or active zeroisation triggers required for hardware security module validation. This action is tempting because administrators frequently perform version checks during routine maintenance and compliance audits to ensure cryptographic software is up-to-date. Such a procedure would be the correct choice when conducting a vulnerability assessment or software patch management review to protect against remote exploits and software-level flaws.

Test the HSM's response to an incorrect PIN retry threshold.

Why it fails: Testing an HSM's PIN retry threshold verifies logical access controls and brute-force resistance by checking if the device locks out administrators after a specified number of failed authentication attempts. While this procedure is essential for validating operational authentication security, it fails to meet the specific annual validation requirement to inspect the device's physical security posture, such as tamper-evident seals, enclosure integrity, or zeroisation circuitry. This action would be the correct choice during an administrative access control review or security configuration audit focusing strictly on logical credential boundaries.

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.

Direct the operations team to encrypt the tapes immediately and update the security plan, since the ISSEP has authority over security configuration of accredited systems.

Why it fails: While encryption is the technically preferable control, the ISSEP does not hold configuration authority over the system and cannot unilaterally direct operations changes. Imposing a fix without the system owner's involvement or an updated authorization package undermines configuration management and the accreditation baseline. The correct path is to recommend the control and let the responsible authorities decide.

Document the risk acceptance in the plan of action and milestones and allow the system owner to proceed without further action.

Why it fails: A plan of action and milestones is used to track remediation of known weaknesses, not to authorize an unresolved risk that may violate data handling requirements for classified information. Allowing the owner to proceed would bypass the Authorizing Official's authority. The ISSEP cannot accept risk on the owner's behalf, and this path leaves the classified data exposed with no formal risk decision.

Perform a new quantitative risk assessment to calculate the Annualized Loss Expectancy of tape loss and let the resulting dollar value determine whether the risk is acceptable.

Why it fails: Quantitative methods cannot capture the national security consequences of classified data loss, and a dollar threshold is not the criterion for accepting risk to classified information. The scenario involves policy and authorization questions, not a purely financial trade-off. Recomputing ALE would delay the necessary escalation and mischaracterize a decision that belongs to the Authorizing Official.

L2TP without IPsec

Why it fails: L2TP without IPsec does not provide encryption or confidentiality; it only tunnels PPP sessions. Without IPsec, data is transmitted in cleartext, and there is no integrity or mutual authentication. This would violate the requirement to protect sensitive data in transit. Therefore, L2TP alone is not suitable.

PPTP with MS-CHAPv2

Why it fails: PPTP with MS-CHAPv2 is obsolete and has known vulnerabilities, including weak authentication and encryption. It does not provide strong confidentiality or integrity, and mutual authentication is not robust. Using PPTP would expose sensitive data to interception and tampering. Thus, it fails to meet the security requirements for this system.

SSL/TLS VPN using only server-side certificates

Why it fails: An SSL/TLS VPN using only server-side certificates provides confidentiality and integrity, but it does not provide mutual authentication because the client is not authenticated with a certificate. The server authenticates to the client, but the client may only use a password, which is weaker. The requirement explicitly states mutual authentication, so this option fails.

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.

Maximal feature set

Why it fails: Maximising the feature set expands the system's attack surface and introduces unnecessary software dependencies, directly undermining survivability by creating complex failure points that degrade graceful degradation under duress. This approach is tempting during the initial design phase because a rich capability matrix satisfies broad functional requirements and addresses diverse stakeholder use cases. Pursuing a maximal feature set would be the correct choice when engineering a general-purpose enterprise productivity platform where comprehensive feature delivery outweighs resilience against targeted attacks or severe infrastructure faults.

Hardware redundancy only

Why it fails: Relying solely on hardware redundancy fails system survivability because it only guards against physical component failure, leaving the architecture vulnerable to software corruption, persistent cyber attacks, and logical faults that bypass physical failovers. This approach is typically selected to maintain high availability against sudden power outages or physical device breakdowns by offering mirrored physical components. In a scenario strictly limited to mitigating isolated hardware degradation without systemic threats, deploying duplicate physical infrastructure would be the correct choice to ensure continuous operation.

Complete system lockdown upon error

Why it fails: Locking down a system entirely upon detecting an error destroys operational resilience by completely halting processing, directly violating the survivability requirement to maintain essential services under duress. This approach stems from fail-secure architectures designed to prevent unauthorised access or data exfiltration during a suspected compromise. In high-security scenarios requiring the absolute confidentiality of classified data storage, transitioning immediately to a restricted, zero-trust offline state is the mandatory design choice, whereas survivability prioritises graceful degradation and continuity of core functions.

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.

Clark-Wilson model

Why it fails: The Clark-Wilson model focuses on commercial integrity through well-formed transactions and separation of duties. It does not define a lattice of sensitivity levels or a no-write-down rule for confidentiality. While it can enforce constraints on how data is modified, it does not directly address the MLS confidentiality requirement of preventing a higher-level subject from writing to a lower-level object.

Graham-Denning model

Why it fails: The Graham-Denning model specifies a set of primitive operations for secure access control, such as creating and deleting objects and subjects, but it does not define a confidentiality lattice or a no-write-down property. It is a generic access control model rather than a multi-level confidentiality model. It would not inherently prevent a Top Secret subject from writing to a Secret object.

Biba integrity model

Why it fails: The Biba model addresses integrity, not confidentiality. It prevents subjects from reading lower-integrity data or writing to higher-integrity objects, which is the opposite direction of the no-write-down confidentiality rule. Applying Biba here would not stop a Top Secret subject from writing to a Secret object; it would instead focus on preventing contamination of higher-integrity data by lower-integrity sources.

AU-2 Audit Events

Why it fails: Auditing mechanisms focus on generating and recording system logs for forensic analysis and compliance tracking, failing this scenario because they govern event logging rather than the procurement, contractual integration, and lifecycle oversight of acquired system components. This distractor is tempting because administrators routinely configure audit policies to monitor changes made to security baselines, making it the correct choice when addressing requirements for tracking auditable events, user actions, and security-relevant system occurrences within the AU family of controls.

SC-8 Transmission Confidentiality

Why it fails: SC-8 focuses exclusively on protecting data in transit using cryptographic mechanisms such as TLS or IPsec, making it irrelevant to the procurement, supply chain, and baseline configuration management of systems specified in the stem. Professionals often confuse transmission security with broader system acquisition controls because secure baseline configurations are frequently bundled into vendor delivery requirements. This option would be correct if the migration scenario specifically evaluated securing communication channels between distributed server nodes against eavesdropping and interception.

AC-3 Access Enforcement

Why it fails: Access Enforcement governs runtime authorization checks for subjects interacting with objects based on security policies, failing this scenario because it addresses active access control rather than supply chain acquisition and system provenance. It is tempting because server migrations involve rigorous permission boundaries, making it the correct choice when restricting user or process access to specific migration assets and directories during the operational deployment phase.

The risk is model poisoning; manage by sanitizing the training data.

Why it fails: Concept drift refers to the degradation of model performance caused by evolving data distributions, whereas model poisoning involves the intentional injection of malicious samples to manipulate training outcomes. Sanitising training data addresses adversarial input manipulation but fails to rectify the underlying statistical shift inherent in concept drift. This option is tempting because both phenomena involve compromised model integrity; however, poisoning requires defensive data filtering, while concept drift necessitates continuous retraining or model recalibration to align with the current operational environment.

The risk is model inversion; manage by adding differential privacy.

Why it fails: Model inversion involves an attacker reconstructing training data from model outputs, whereas concept drift refers to the degradation of predictive accuracy due to changing data distributions over time. While differential privacy mitigates privacy leakage by injecting noise into training sets, it does not address the performance decay caused by evolving fraud patterns. This option is tempting because differential privacy is a standard security control for machine learning pipelines, yet it targets confidentiality threats rather than the temporal model stability required here.

The risk is a data breach; manage by encrypting the dataset.

Why it fails: Encryption protects data confidentiality at rest or in transit but fails to address the predictive performance degradation caused by evolving statistical properties in input data. Concept drift requires model retraining or continuous monitoring of feature distributions to maintain accuracy. Encryption is a valid control for preventing unauthorised access to sensitive information, such as protecting PII within a database or securing authentication tokens managed by Microsoft Entra ID, yet it provides no mechanism to detect or mitigate the loss of model validity over time.

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.

Validate the TPM version is 2.0.

Why it fails: Secure Boot validation concerns the platform key, key exchange keys and signature database entries in UEFI firmware, not the TPM version. It tempts because TPM 2.0 is often required alongside Secure Boot for measured boot, but TPM version alone does not verify bootloader signature enforcement.

Check that 'Legacy Boot' is set to 'Disabled'.

Why it fails: Disabling Legacy Boot removes BIOS/CSM compatibility but does not itself validate the secure boot chain; Secure Boot must be Enabled and its keys (PK/KEK/db) present. Legacy Boot is disabled by default on UEFI-only deployments, so it is tempting when hardening firmware against unsigned OS loaders.

Ensure the system clock is synchronized with a secure NTP server.

Why it fails: Secure Boot validation requires checking the UEFI signature databases and enrolled platform keys, not NTP synchronisation. It tempts because accurate time supports certificate validity checks, but clock sync does not verify that firmware is enforcing signed bootloader verification.

Reviewing the change management ticketing system for approved change requests each week

Why it fails: Weekly review of tickets identifies whether documented changes were authorized, but it neither inspects server state nor operates within one hour. Unauthorized changes made outside the ticketing process would be invisible. This activity supports process compliance and audit trails for approved changes, yet it cannot detect configuration drift on production servers in the required timeframe.

A quarterly manual configuration audit performed by the security team

Why it fails: A quarterly audit samples settings at a point in time and cannot detect a change within one hour. Between audits, unauthorized modifications can persist undetected for weeks. Manual audits also depend on sampling and reviewer diligence. While they provide governance evidence, they fail the explicit one-hour detection requirement, so they cannot demonstrate compliance with the stated timing objective.

File integrity monitoring configured to watch only the operating system kernel binaries

Why it fails: File integrity monitoring can detect changes quickly, but scoping it to kernel binaries leaves security-relevant settings such as audit policy, firewall rules, and authentication configuration unwatched. The scenario requires detection of unauthorized changes to security-relevant settings broadly, so a narrowly scoped monitor cannot provide the needed coverage regardless of how fast it runs.

Performing an independent penetration test of the provider's hypervisor layer

Why it fails: Penetration testing the provider's hypervisor is typically prohibited by the cloud service agreement and would not resolve the mapping question. The Authorizing Official wants a documented determination of which controls are inherited, shared, or customer-owned, not offensive testing of infrastructure the organization does not control.

Re-categorizing the system at a higher FIPS 199 impact level to reflect cloud exposure

Why it fails: FIPS 199 categorization is based on the potential impact of loss of confidentiality, integrity, and availability, not on deployment location. Raising the impact level does not identify inherited or shared controls and would not satisfy the Authorizing Official's request for a clear responsibility mapping.

Requesting a new Authority to Operate directly from the cloud provider's authorizing official

Why it fails: The cloud provider's authorization covers the provider's own boundary and services, not the customer's system. A customer organization cannot obtain an ATO from the provider's authorizing official; it must rely on the provider's package for inheritance evidence and pursue its own authorization for the customer-owned portions.

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.

The blockchain's cryptographic hash functions may be broken in the future.

Why it fails: While cryptographic algorithms can eventually be deprecated, this is a long-term risk that applies to all cryptographic systems. It is not unique to blockchain and can be managed through crypto-agility. For the current assessment, it is not the most significant residual risk compared to data integrity at the source.

The audit logs may become too large to store on the blockchain.

Why it fails: Scalability is a valid concern, but it affects availability and performance rather than the tamper-evident property. The system could use off-chain storage with on-chain hashes. This is an operational risk, not the primary residual risk regarding the integrity of the audit trail.

The blockchain's consensus algorithm may be vulnerable to a 51% attack.

Why it fails: A 51% attack is a concern for public blockchains, but in a permissioned enterprise blockchain used for audit logs, the consensus participants are typically known and trusted. The risk is lower and can be mitigated through governance. While not impossible, it is not the most significant residual risk for a tamper-evident audit log system.