Risk Management practice questions

Perform a full system penetration test.

Why it fails: While useful, it may not be necessary to perform a full test if only specific components changed.

Notify the system users of the update.

Why it fails: Communicating updates to users addresses operational awareness and change management, but it fails to validate the security controls or assess the residual risk introduced by the software modifications. While notifying stakeholders is a standard administrative requirement for maintaining user trust and ensuring compliance with acceptable use policies during scheduled maintenance windows, it does not perform the technical security impact analysis or control re-verification mandated by the RMF Maintain phase to ensure the system’s authorisation remains valid.

Update the system backup schedule.

Why it fails: Adjusting backup schedules addresses data availability and recovery objectives rather than validating the security controls affected by a software update. While maintaining backups is essential for disaster recovery and business continuity planning, it does not evaluate whether new code introduces vulnerabilities or alters the system's authorisation boundary. This activity becomes necessary when data retention policies change or storage capacity requirements shift, but it lacks the security impact assessment and continuous monitoring required to confirm that the system's security posture remains intact following a modification.

Patch management complexity increases due to the number of functions.

Why it fails: Although managing numerous distinct Lambda functions could theoretically introduce administrative overhead, this option fails because serverless computing entirely removes OS-level patching responsibilities from the tenant, irrespective of function count. This distracts because administrators managing hundreds of discrete microservices in traditional environments face severe configuration drift and patch fatigue. Such an argument WOULD be the correct choice when evaluating architectural complexity scaling in containerised or virtual machine fleets where operating systems remain under tenant control and require individual maintenance pipelines.

The user must now use a specialized patching tool for the serverless platform.

Why it fails: Serverless architectures abstract the underlying operating system entirely, meaning the cloud provider assumes full responsibility for patching the runtime environment, rendering user-managed patching tools redundant. This option appeals to candidates familiar with traditional Infrastructure as a Service (IaaS) models, where administrators must deploy automated patch management suites to maintain virtual machine security. Such tools remain necessary when managing persistent guest operating systems, but they provide no functional utility within an ephemeral, provider-managed execution environment where the user lacks infrastructure access.

The user is no longer responsible for any patching.

Why it fails: Although serverless architectures eliminate OS-level maintenance, developers remain fully responsible for updating application source code and third-party dependencies, such as npm packages or Python libraries packaged within the deployment artifact. This misconception arises because managed Function-as-a-Service platforms fully abstract underlying hypervisors, operating systems, and runtimes, which would represent the correct security division if the organisation were evaluating physical infrastructure decommissioning rather than software-level vulnerability management.

Store the keys in a hardcoded configuration file.

Why it fails: Hardcoded configuration files expose encryption keys in plaintext within the device's storage media, leaving them trivial to extract via firmware reverse-engineering or memory dumping when dedicated cryptographic hardware is absent. Developers are often tempted to use static configuration files during rapid prototyping because they streamline initial deployment by removing complex runtime provisioning steps. In non-security-critical applications or internal development environments where confidentiality of the payload is irrelevant, this approach provides a straightforward method to instantiate parameters without administrative overhead.

Store the keys in the system's non-volatile memory (NVM) with XOR masking.

Why it fails: XOR masking is fundamentally a lightweight obfuscation technique rather than cryptographic protection, making it vulnerable to trivial reverse-engineering and static analysis by an attacker with physical access to the non-volatile memory. Engineers are often tempted by this approach in constrained embedded designs because it requires minimal computational overhead and avoids complex key derivation functions, making it a viable choice only for deterring casual inspection in low-risk consumer electronics where high-assurance confidentiality is neither mandated nor expected.

Utilize a TEE (e.g., ARM TrustZone) to isolate keys and perform cryptographic operations.

Why it fails: A TEE provides a hardware-isolated environment that protects keys even if the main OS is compromised.

NIST SP 800-53.

Why it fails: 800-53 defines security controls, not coding standards.

ISO/IEC 27001.

Why it fails: ISO 27001 is for Information Security Management Systems, not coding standards.

ITIL v4.

Why it fails: ITIL is for IT service management.

Increased security of data at rest.

Why it fails: Homomorphic encryption is specifically designed to allow computation on data while it remains encrypted, protecting information during active processing rather than storage. While safeguarding data at rest is a critical architectural requirement, standard encryption standards like AES already achieve this efficiently without the extreme CPU and memory overhead introduced by homomorphic schemes. Therefore, this option fails because it misidentifies the operational trade-off, which revolves around processing capability versus cryptographic overhead rather than passive storage security. Standard cryptographic storage solutions would be the correct choice when data only requires confidentiality while stationary on disk.

Incompatibility with standard database engines.

Why it fails: While this is a challenge, it is a secondary issue to the primary performance impact.

Complexity of key management.

Why it fails: Key generation and lifecycle governance are fundamentally decoupled from the mathematical evaluation of ciphertexts, rendering cryptographic key administration an orthogonal concern to the operational processing trade-offs mandated by homomorphic schemes. Administrators often select this distractor because managing public-private key pairs, rotation schedules, and access policies is universally required in asymmetric cryptography, which would indeed become the primary operational hurdle in scenarios involving strict regulatory key-custody mandates or multi-tenant cloud storage isolation.

Avoid the risk by replacing the COTS hardware with custom-developed hardware that can be fully inspected.

Why it fails: Replacing COTS with custom hardware is often cost-prohibitive, time-consuming, and may introduce new risks. It is not the most appropriate immediate strategy when mitigation options exist. The ISSEP should first apply available controls to manage the risk before considering avoidance, which is typically a last resort.

Transfer the risk by purchasing cyber insurance that covers supply chain attacks.

Why it fails: Cyber insurance may offset financial losses but does not reduce the likelihood or technical impact of a supply chain attack. It also does not address the lack of firmware inspection. Risk transfer is a financial tool, not a substitute for technical risk mitigation, especially for mission-critical systems where integrity is paramount.

Accept the risk because the vendor provides an SBOM, which is sufficient to identify all components.

Why it fails: An SBOM lists components but does not guarantee their security or provenance. It cannot detect malicious firmware implants or vulnerabilities that are not disclosed. Accepting the risk solely based on an SBOM ignores the limited visibility into firmware and the potential for supply chain compromise. Additional mitigations are needed.

The risk is medium because the average of likelihood and impact is 4.5, which falls in the medium range.

Why it fails: Risk is not calculated by averaging likelihood and impact; it is typically the product or a matrix intersection of the two. Averaging loses the multiplicative relationship that makes high-likelihood, high-impact risks severe. A 4 and 5 on a 1-5 scale is a high risk, not medium. This response uses an incorrect formula and would lead to under-prioritizing the vulnerability.

The risk is low because likelihood and impact are separate dimensions and should not be combined.

Why it fails: Likelihood and impact are the two standard dimensions of risk and are routinely combined in a risk matrix or risk score. Treating them as independent and concluding the risk is low misrepresents the assessment. A likelihood of 4 and impact of 5 indicates a high-exposure risk that warrants management attention, not dismissal. This response misapplies risk assessment fundamentals.

The risk cannot be evaluated until a monetary value is assigned to the impact, so the program manager should wait for a quantitative assessment.

Why it fails: Qualitative or semi-quantitative risk scales are valid and widely used when monetary data is unavailable or unnecessary. Requiring a full quantitative assessment before communicating urgency delays decision-making. The program manager needs an actionable characterization now; the qualitative score already provides that. Waiting for monetary valuation is not required to identify this as a high-priority risk.

$200,000

Why it fails: Calculating the Annualized Loss Expectancy requires multiplying the Annualized Rate of Occurrence by the Single Loss Expectancy, which yields $50,000 rather than $200,000. This figure arises if an individual mistakenly divides the Single Loss Expectancy by the Annualized Rate of Occurrence, a calculation error often made when attempting to derive the total loss value from an inverse frequency. Such a result would only be valid if the Annualized Rate of Occurrence were 0.25, representing a different frequency of threat realisation.

$500,000

Why it fails: Multiplying the Single Loss Expectancy by the Annualized Rate of Occurrence yields $50,000, rendering this $500,000 figure mathematically erroneous. This value arises if a candidate mistakenly multiplies by ten rather than 0.5, perhaps confusing the ARO with a decadal frequency. Such a result would only be valid if the threat event occurred five times per year instead of once every two years, representing a significant miscalculation of the expected financial impact over a twelve-month period for this specific database asset.

$100,000

Why it fails: Calculating the Annualized Loss Expectancy requires multiplying the Annualized Rate of Occurrence by the Single Loss Expectancy, which yields $50,000 rather than $100,000. This figure represents the Single Loss Expectancy itself, which is the monetary value of a single security incident. Candidates often select this value when they conflate the total projected annual loss with the cost of an individual event, failing to account for the frequency of occurrence specified in the scenario.

The sensor housing is not tamper-evident.

Why it fails: Physical tampering with a single sensor housing represents a localised threat rather than a systemic failure, as it does not compromise the integrity of the broader network architecture or the data pipeline. This option appears attractive because physical security is a fundamental component of supply chain risk management; it would be the primary concern in scenarios involving high-value, standalone assets where individual device compromise leads directly to the theft of sensitive local data or the introduction of malicious firmware via physical ports.

The sensors use an older version of Bluetooth.

Why it fails: Version issues are technical risks but generally less systemic than an unverifiable code supply chain.

The vendor does not provide a Service Level Agreement (SLA).

Why it fails: While important for operations, lack of an SLA is a business risk, not a system integrity risk.

Update the security policy to include manual verification of boot logs.

Why it fails: Relying on manual verification of boot logs fails to address the underlying hardware vulnerability because administrative oversight cannot patch firmware or prevent physical key-injection attacks against a compromised Trusted Platform Module. This approach is tempting as an administrative detective control used to satisfy compliance auditing requirements and monitor system integrity anomalies. Such a policy would be appropriate in an operational scenario where legacy hardware cannot be physically or logically patched, serving as a compensating control to detect unauthorized boot state modifications rather than remediating the cryptographic flaw itself.

Configure an IDS to block unauthorized firmware update attempts.

Why it fails: Deploying an Intrusion Detection System focuses on network and host monitoring to identify malicious traffic or behavioral anomalies, making it tempting for boundary defence when external threats are suspected. However, this measure fails here because an IDS cannot patch, remediate, or mitigate an existing cryptographic flaw residing within the physical Trusted Platform Module firmware itself. The vulnerability stems from vulnerable code stored directly in the hardware component rather than active network exploitation, meaning monitoring traffic leaves the core supply-chain weakness unaddressed; an IDS would be the correct choice if the scenario described active exploitation of network services rather than an inherently vulnerable hardware firmware version requiring direct patching or replacement.

Disable TPM-based secure boot until the vendor releases a patch.

Why it fails: Disabling TPM-based secure boot entirely removes the root of trust required to validate system integrity, leaving the platform completely exposed to bootloader tampering and unauthorized firmware modifications. This approach is tempting because temporarily isolating or disabling a vulnerable component is a standard incident-response containment strategy designed to mitigate active exploitation risks. Consequently, this action would be appropriate if the vulnerability allowed active remote code execution during the boot phase and no compensating controls existed, provided the operational risk of downtime was deemed acceptable while awaiting a vendor patch.

That the system uses TLS 1.3 for data in transit.

Why it fails: TLS 1.3 focuses on secure communication protocols rather than the hardware or software cryptographic module validation required by FIPS 140-3. While TLS 1.3 is essential for protecting data in transit and ensuring modern transport security, it does not mandate that the underlying cryptographic primitives are implemented within a FIPS-validated boundary. This option appears relevant because engineers often prioritise transport security during design, yet FIPS 140-3 specifically governs the integrity and physical security of the cryptographic modules themselves, not the protocol layer.

That the cloud management console uses Multi-Factor Authentication (MFA).

Why it fails: Multi-factor authentication secures administrative access to the management console but does not address the cryptographic module validation required by FIPS 140-3. While implementing MFA via Microsoft Entra ID is a fundamental security control for identity and access management, it remains orthogonal to the hardware or software encryption standards mandated by FIPS. This option is tempting because it represents a critical security best practice for cloud governance, yet it fails to validate the underlying cryptographic algorithms or modules protecting the data at rest and in transit.

That the cloud provider's storage is encrypted at rest.

Why it fails: FIPS 140-3 validates cryptographic modules, so the ISSEP must verify that approved, validated modules perform the encryption and key management; encryption at rest alone says nothing about module validation. It is tempting because encryption at rest is a common compliance control, and it would be correct if the requirement were data confidentiality rather than FIPS validation.

Replace the proprietary protocol with OPC-UA to enable standard security monitoring.

Why it fails: Replacing a proprietary protocol with OPC-UA introduces significant operational risk by requiring extensive downtime and potential hardware incompatibility within a live industrial environment. While OPC-UA facilitates interoperability and standardises security monitoring for modernised infrastructures, the immediate requirement is to secure an existing, non-standard system without disrupting critical processes. This approach is valid during a planned lifecycle replacement or greenfield deployment, but it fails to address the immediate need for threat visibility in a legacy system that cannot undergo such fundamental architectural changes.

Implement a host-based firewall on the SCADA master station.

Why it fails: Host-based firewalls operate at the endpoint level, meaning they cannot inspect or filter traffic traversing the network between distributed field devices and the master station. While these firewalls effectively harden the master station against unauthorised local access or direct service exploitation, they fail to mitigate threats originating from compromised network segments or lateral movement within the proprietary protocol environment. This security measure is essential for protecting individual server resources from internal attacks, but it lacks the visibility required to secure non-standard industrial communication streams.

Deploy an intrusion detection system (IDS) that uses behavioral pattern matching.

Why it fails: Behavioural IDS matches known-bad activity patterns and anomalies, so it cannot inspect the proprietary protocol's payloads or commands, leaving the SCADA attack surface largely unmonitored. It would be the right choice where traffic is standard and signatures or baselines exist; here a SCADA-aware passive monitor or protocol-aware appliance is needed.

Encrypt the model weights at rest.

Why it fails: Encrypting weights at rest protects the stored model file from disk theft, yet inversion exploits the model's own predictions at inference time, where weights are decrypted and usable. Encryption at rest suits data-at-rest compliance; inference-time protections such as output perturbation or query limits address reconstruction.

Implement rate limiting on the model's API.

Why it fails: Rate limiting throttles request volume, but a single query can still reconstruct training data through repeated inference; it mitigates abuse and denial-of-service, not inversion. Differential privacy, which adds calibrated noise to training or outputs, is the control that bounds what any individual query can reveal.

Retrain the model on a smaller, obfuscated dataset.

Why it fails: Reducing the dataset size or obfuscating inputs fails to provide a mathematical guarantee against reconstruction, as model inversion exploits the inherent memorisation of training samples within the model weights. While data sanitisation helps mitigate privacy leakage during the initial training phase, it does not address the fundamental vulnerability of an already deployed model. This approach is useful for general data minimisation and privacy-by-design principles when preparing training pipelines, but it lacks the specific adversarial robustness required to prevent extraction attacks on active inference endpoints.

Modify the Security Assessment Plan (SAP) to exclude the container layer from the current assessment scope.

Why it fails: Arbitrarily narrowing the scope of an assessment violates the integrity of the risk assessment process.

Proceed to authorization and defer the container baseline to the next Continuous Monitoring cycle.

Why it fails: Delaying baseline implementation during the assessment phase creates an unacceptable risk window for the authorization official.

Request a waiver from the Chief Information Security Officer (CISO) for container orchestration security.

Why it fails: Waivers should be a last resort and are inappropriate when a standard technical solution like IaC is available.

Accept the risk because the API is internal-facing.

Why it fails: Assuming an internal network boundary provides sufficient protection misjudges modern threat modeling, as perimeter-based defences fail to stop lateral movement once an attacker compromises an internal segment or adjacent service. This strategy is tempting because internal-facing systems operate within a controlled corporate network and generally process trusted internal traffic, making it a viable approach when dealing with legacy components that reside behind strict hardware firewalls and isolated virtual local area networks, provided zero-trust segmentation policies are rigorously enforced.

Disable the API entirely.

Why it fails: Disabling the API removes the business capability entirely rather than managing the residual risk, which is disproportionate when the service is still needed. It is tempting because it eliminates exposure outright, and would be correct only where the API is non-essential and no compensating control exists.

Monitor API logs for suspicious activity.

Why it fails: Relying solely on reviewing audit trails is ineffective here because logging is a reactive detective control that records exploits after they occur rather than preventing unauthorised access caused by weak authentication. This approach appeals to security practitioners because centralised log aggregation is essential for forensic analysis and compliance auditing. Monitoring logs would be the correct choice if the objective were to detect post-compromise lateral movement or compile an incident timeline after a breach has already been identified.

Require MFA for workstation access.

Why it fails: Multi-factor authentication protects against compromised credentials by verifying user identity, making it a tempting countermeasure when securing administrative access to sensitive industrial networks. This would be the correct choice if the vulnerability stemmed solely from weak passwords allowing unauthorized remote login to the workstation. However, implementing authentication credentials fails to mitigate network-layer exposure in this scenario. Because the workstation resides natively on the programmable logic controller VLAN, an attacker who successfully authenticates or compromises the endpoint can immediately execute lateral movement, ARP spoofing, or direct layer-2 attacks against critical industrial controllers without encountering further network segmentation.

Install an antivirus on the workstation.

Why it fails: Antivirus on the workstation addresses malware on that host but does not remove its Layer 2 adjacency to the PLCs, so compromised or malicious traffic still reaches controllers directly. It is tempting as endpoint hardening, yet the risk stems from shared VLAN segmentation, which inter-zone firewalling or VLAN separation resolves.

Disable all unused ports on the PLC network switch.

Why it fails: Disabling unused switch ports reduces physical attack surface but leaves the administrative workstation sharing the PLC VLAN, so it can still reach controllers directly. It is tempting as basic switch hardening, yet the identified risk is flat network segmentation, which VLAN separation or a firewall between zones actually addresses.

Incompatibility with cloud-based storage.

Why it fails: Centralised databases integrate seamlessly with cloud-native storage layers like Amazon S3 or Azure Blob Storage via standard connection strings and secure endpoints, rendering architectural incompatibility a non-factor. This distractor appears plausible because practitioners frequently evaluate cloud migration strategies when modernising personally identifiable information repositories, making cloud storage evaluation a standard architectural activity. It would be the correct choice if the primary technical constraint involved migrating legacy on-premises database instances to distributed object storage arrays without altering application logic.

Increased latency for data retrieval.

Why it fails: While database latency directly affects user experience during high-volume queries, it represents an operational performance bottleneck rather than the core security failure regarding Personally Identifiable Information storage. Centralising data storage is actually intended to simplify compliance audits, enforce uniform access controls, and streamline data governance across an organisation. In scenarios requiring strict master data management and unified logging, a centralised architecture remains ideal; however, for this specific security review, the primary concern centres on data exposure and the single point of failure rather than retrieval speed.

Difficulty in performing data backups.

Why it fails: Centralised databases actually simplify backup procedures by consolidating storage into a single administrative domain, making scheduled snapshots and disaster recovery routines straightforward to execute. This approach is typically selected for high-availability enterprise applications requiring transactional consistency and unified storage management, where a single point of backup administration reduces operational overhead. However, the scenario specifically focuses on the architectural risks of personally identifiable information exposure, rendering backup execution irrelevant to the primary vulnerability.

Risk of unauthorized access by the cloud provider's employees.

Why it fails: Cloud provider employee access represents a significant operational security concern regarding administrative privilege abuse and insider threats, making it tempting to select when evaluating cloud risks. However, this administrative exposure is inherent to any outsourced cloud deployment model—including single-tenant private clouds and dedicated hosted infrastructure—rather than being technically unique to multi-tenancy. A risk assessment specifically targeting multi-tenant environments must isolate vulnerabilities arising from shared physical resources, hypervisor boundary failures, and logical isolation flaws between distinct customer tenants sharing the same underlying hardware platform.

Difficulty in performing system backups.

Why it fails: Backups are universally applicable across single-tenant, multi-tenant, and on-premises architectures, meaning the challenge of capturing and restoring data stems from standard disaster recovery planning rather than shared infrastructure boundaries. This choice is tempting because cloud service providers often restrict direct access to hypervisor-level storage volumes, shifting backup responsibilities through a shared responsibility model. Consequently, this constraint surfaces when evaluating operational governance or compliance mandates in outsourced models, but it does not represent an exposure specifically driven by concurrent resource sharing among untrusted tenants.

Risk of data loss due to provider bankruptcy.

Why it fails: Financial instability and subsequent liquidation affect any outsourced infrastructure model, including single-tenant dedicated hosting and traditional colocation facilities, meaning vendor insolvency is not a structural consequence of shared resource pools. This choice is tempting because cloud governance frameworks universally mandate escrow arrangements and continuity planning for provider insolvency, making it a critical financial risk metric during third-party due diligence. However, it fails in this scenario because multi-tenancy specifically introduces architectural vulnerabilities involving logical boundary isolation, noisy neighbours, and hypervisor escape vulnerabilities that do not exist in single-tenant deployments.

Implement a dual-factor authentication requirement for HSM access.

Why it fails: Requiring dual-factor authentication controls administrative logical access to the cryptographic module, yet does nothing to defend against physical or environmental emissions exploited during execution. This countermeasure is tempting because administrators frequently conflate logical authentication boundaries with physical security controls, assuming stringent sign-in policies protect underlying hardware. It would be the correct choice if the threat actor were attempting unauthorised remote logins or privilege escalation rather than measuring power consumption or electromagnetic radiation from the silicon chip.

Increase the length of the RSA keys.

Why it fails: Extending key length does nothing to halt side-channel attacks because the adversary intercepts physical emissions—such as power consumption, electromagnetic radiation, or execution timing—during mathematical operations, bypassing the mathematical complexity of the algorithm entirely. This strategy is typically employed to protect against brute-force mathematical cryptanalysis or factoring attacks where the primary vulnerability is insufficient key space. In a scenario where an attacker targets the computational workload over an extended key life or attempts exhaustive search, larger keys are essential; however, they leave the physical hardware vulnerable to observable operational leakage.

Use a larger number of HSMs in a cluster.

Why it fails: Clustering multiple Hardware Security Modules distributes computational workload and enhances high availability or throughput, making this strategy tempting when scaling a busy code-signing infrastructure. However, adding more devices does nothing to alter the physical leakage profile of the individual cryptographic processors. Because side-channel attacks exploit physical emanations—such as power consumption or electromagnetic radiation—observed during internal cryptographic operations, simply multiplying the number of vulnerable hardware units leaves each individual HSM just as susceptible to physical measurement and cryptographic key extraction.

The vendor's marketing materials.

Why it fails: Vendor marketing materials lack the technical depth and binding security specifications required to establish a comprehensive risk baseline for a new system. These documents serve primarily to highlight high-level product features and competitive advantages during the initial procurement or market research phase. While they provide a useful overview of intended functionality for stakeholders evaluating potential solutions, they fail to detail the specific security controls, configuration requirements, or architectural constraints necessary for a rigorous risk assessment.

The project budget.

Why it fails: Financial constraints dictate the scope of resource acquisition and project feasibility rather than defining the technical security controls or regulatory mandates required for system hardening. While this document is essential for project managers to track expenditure and allocate funding during the procurement phase, it lacks the functional specifications and security baselines necessary to identify system vulnerabilities. An ISSEP must prioritise security requirement documentation, such as the System Security Plan, to ensure comprehensive coverage of technical controls during the initial assessment phase.

The organizational chart.

Why it fails: An organisational chart defines reporting lines and administrative hierarchies, failing to document the technical security controls or functional requirements necessary for a risk assessment. While this document assists in identifying stakeholders, data owners, or personnel with specific system access privileges during a business impact analysis, it lacks the technical specifications required to evaluate system vulnerabilities. It serves administrative governance rather than the technical security baseline validation that an ISSEP must prioritise when assessing system-wide security requirements.