Cybersecurity Principles And Risk practice questions

Vulnerability assessment

Why it fails: Vulnerability assessment identifies weaknesses in the critical assets, but it follows the threat identification and asset valuation steps that establish what is being protected and from what. Jumping straight to vulnerabilities skips those preceding stages. It would be correct after assets and threats are documented.

Acceptable risk levels

Why it fails: Acceptable risk levels are defined after vulnerabilities are assessed and risks analysed, since thresholds depend on quantified likelihood and impact. Choosing this immediately after asset identification omits the vulnerability assessment step that produces those risk values. It would be correct once risks are known and tolerance must be set.

Risk mitigation strategy

Why it fails: Risk mitigation strategy follows the full assessment cycle, once vulnerabilities, likelihood and impact have been evaluated and acceptable levels set. Selecting it here skips the vulnerability assessment and risk-level determination that must precede any treatment decision. Mitigation would be correct after risks are quantified and prioritised.

Least Privilege

Why it fails: Least privilege applies to user access rights.

Separation of Duties

Why it fails: This prevents fraud by requiring two people.

Defense-in-depth

Why it fails: This involves layering controls.

Job Rotation

Why it fails: Rotation is for detecting fraud, not preventing it in real-time.

Mandatory Access Control

Why it fails: This is a technical access model based on sensitivity labels.

Least Privilege

Why it fails: This is about access rights, not approval processes.

System hardening

Why it fails: System hardening belongs to the Protect function, reducing attack surface through configuration baselines rather than identifying incidents. It tempts because hardened systems produce fewer alerts, but hardening is preventive; Detection requires monitoring, logging and anomaly analysis capabilities.

Backups

Why it fails: Backups fall under the Recover function, restoring data after an incident rather than identifying one. It tempts because backup logs can reveal failures, but the backup process itself is recovery-oriented; Detection covers continuous monitoring, event analysis and anomaly identification.

Firewall blocking

Why it fails: Firewall blocking is a Protect function under the NIST CSF, preventing traffic rather than identifying events. It tempts because firewalls generate logs that feed detection, but the blocking action itself sits in Protect; Detection covers continuous monitoring and anomaly identification.

Malware scanning

Why it fails: This is part of Protect/Detect.

Incident recovery time analysis

Why it fails: This is part of Recovery.

Immediately decommission the legacy payroll application

Why it fails: Decommissioning a payroll system without a migration path would disrupt compensation for the entire workforce and is not a first-step recommendation. The analyst's role is to escalate the untreated risk for a formal decision, not to unilaterally remove a business-critical system. Remediation sequencing belongs to the risk owner and business leadership after proper analysis.

Lower the risk rating to 'Medium' to reflect the application's age

Why it fails: Risk ratings derive from likelihood and impact, not from how long an asset has existed. Arbitrarily downgrading a High rating to close a stale entry is a data-integrity violation and would misrepresent residual risk to leadership. The analyst has no authority to alter ratings without new assessment evidence, and doing so would mask an unresolved exposure.

Escalate the stale entry to the risk owner for a documented treatment decision

Why it fails: Escalation is reasonable, but escalation alone does not resolve the underlying governance gap of an untreated High risk sitting idle for three cycles. The analyst should first confirm whether a risk owner and treatment decision exist, because an entry with no owner and no plan is a governance failure. Escalation is a component of the correct first action, not the complete answer.

Risk transfer

Why it fails: Risk transfer shifts the financial consequence of a risk to another party, typically through cyber insurance or contractual indemnification. The underlying likelihood and impact of the threat remain unchanged; only who pays for the loss changes. Because the question asks for strategies that reduce likelihood or impact, transfer does not qualify.

Risk acceptance

Why it fails: Risk acceptance means the organization acknowledges the risk and decides to bear it without additional controls, often because the cost of treatment exceeds the potential loss. It does not reduce likelihood or impact. Since the CISO asked for strategies that reduce risk, acceptance fails to meet the stated criterion and is not a correct choice.

Risk avoidance

Why it fails: Risk avoidance eliminates the risk by discontinuing the activity or system that creates it. While avoidance removes the exposure entirely, it does not reduce the likelihood or impact of an existing risk through controls; it removes the risk source. The question specifically contrasts reduction strategies with transfer and avoidance, so avoidance is not a correct choice here.

Risk avoidance

Why it fails: Avoidance eliminates the activity or asset producing the risk, such as decommissioning the router or removing the exposed service. Management keeps the router running unpatched, so the risk remains. It tempts because refusing the patch sounds like avoidance, but the asset is retained.

Risk mitigation

Why it fails: Mitigation reduces the vulnerability's likelihood or impact, such as patching or compensating controls; here management simply declines to patch and accepts the residual exposure. It tempts because mitigation is the usual treatment for unpatched routers, but no control is applied.

Risk transfer

Why it fails: Transfer shifts financial consequence to a third party, typically via insurance or contractual indemnity. Declining a patch neither moves the risk nor involves another party, so exposure stays with the organisation. It tempts because legacy dependencies often prompt insurance, but no transfer occurs here.

Implement TLS encryption

Why it fails: TLS primarily addresses information disclosure.

Implement logging and auditing

Why it fails: Logging and auditing record that tampering occurred after the fact; they do not prevent modification of data or messages in transit. Tampering is mitigated by integrity controls such as MACs, digital signatures or TLS. Auditing is the right control for Repudiation threats, where proving who did what is the goal.

Implement Role-Based Access Control

Why it fails: RBAC governs who may invoke operations, not whether data itself was altered; an authorised user can still tamper. Tampering is mitigated by integrity mechanisms such as MACs, digital signatures or TLS. RBAC is the correct control for Elevation of Privilege, restricting actions to permitted roles.

Two-Factor Authentication

Why it fails: Two-factor authentication verifies a user's identity at sign-in; it does not encrypt data moving across a network. It is tempting because it protects credentials and access, which supports confidentiality of stored resources, but confidentiality in transit requires transport encryption such as TLS.

Hashing Algorithms

Why it fails: Hashing provides integrity, not confidentiality: it is a one-way digest, so anyone intercepting the data can still read the plaintext. It is tempting because hashing verifies that data has not been altered in transit, which would be the right choice when the requirement is integrity checking rather than secrecy.

Digital Signatures

Why it fails: Digital signatures provide authenticity and integrity, not confidentiality: they prove who sent the data and that it was unaltered, but the payload remains readable in transit. They are tempting because they protect data in transit against tampering and impersonation, which would be correct if the requirement were non-repudiation rather than secrecy.

Access Control (AC)

Why it fails: Access Control (AC) governs authorisation decisions and least privilege, but exfiltration by an already-authorised principal falls outside its scope; AC addresses who may reach data, not the transfer itself. It is tempting because many breaches begin with excessive permissions, and AC would be correct when restricting entitlements that granted the access.

Configuration Management (CM)

Why it fails: Configuration Management (CM) governs baselines, change control and hardening settings; it cannot identify an active unauthorised data transfer. It is tempting because misconfigured storage or permissive settings often enable exfiltration, and CM would be the correct family when remediating the insecure configuration that permitted the leak.

Risk Assessment (RA)

Why it fails: Risk Assessment (RA) quantifies likelihood and impact of threats to inform risk decisions; it does not detect or respond to exfiltration events. It is tempting because exfiltration changes an organisation's risk posture, and RA would be the correct family when assessing whether a data-loss scenario warrants mitigation investment.

Packet sniffing on the wire

Why it fails: Packet sniffing threatens confidentiality by passively reading traffic; it does not deny access to the database. It tempts because it is a network attack, and would be correct if the scenario concerned exposure of data in transit rather than service disruption.

Replay attack

Why it fails: A replay attack threatens integrity or authentication by retransmitting captured valid messages, not availability. It tempts because it is an active attack, and would be correct if the scenario concerned forged or duplicated transactions rather than denial of access to the database.

Unauthorized data modification

Why it fails: Unauthorised data modification threatens integrity, altering stored values without permission, not availability. It tempts because it is a serious database attack, and would be correct if the scenario concerned tampered records rather than the database being made unreachable or unusable.

Detect

Why it fails: Detect covers continuous monitoring and anomaly identification, not resilience of critical infrastructure. It is tempting because detection underpins incident response, but maintaining resilience through continuity and recovery planning sits in the Recover function, which Detect does not address.

Protect

Why it fails: Protect covers safeguards such as access control, awareness training and data security, not resilience of critical infrastructure. It is tempting because protective controls reduce incident likelihood, but maintaining resilience through recovery planning and continuity belongs to the Recover function, which Protect does not address.

Identify

Why it fails: Identify covers asset management, risk assessment and governance, not maintaining resilience of critical infrastructure. It is tempting because asset mapping is the exercise's starting point, but resilience through recovery planning and continuity belongs to the Recover function, which Identify does not provide.

System Security Plan (SSP)

Why it fails: An SSP documents the controls implemented for a specific system's authorisation boundary; it does not express enterprise-wide management commitment. It tempts because it is a formal security document, but the top-management commitment is stated in the information security policy.

Business Impact Analysis (BIA)

Why it fails: A BIA quantifies the impact of disruption to business processes and informs continuity priorities; it does not express management's security commitment. It tempts because it is a governance-adjacent document, but the formal top-management commitment is the information security policy.

Standard Operating Procedure (SOP)

Why it fails: An SOP documents step-by-step operational procedures, not top management's formal security commitment. It is tempting because SOPs are governance artefacts that support security objectives, and an SOP would be the correct choice when the requirement is a repeatable procedure for a specific operational task.

To identify all system vulnerabilities

Why it fails: Vulnerability assessment is different from BIA.

To test incident response playbooks

Why it fails: Playbook testing validates response procedures and is a separate exercise, not the BIA's purpose. Testing tempts because both sit within continuity planning, yet a BIA identifies and prioritises critical business functions and quantifies the impact of their disruption, feeding recovery objectives.

To create a list of software patches

Why it fails: Patch lists come from vulnerability and patch management processes, which remediate known software flaws. A BIA determines which business processes are critical and how outages affect them, setting recovery time and point objectives. It is tempting because patching supports resilience, but it produces no impact or dependency analysis.

Inherent risk and residual risk

Why it fails: Inherent and residual risk describe risk before and after controls, forming no part of FAIR's frequency decomposition. They are tempting because both are risk concepts, but they belong to risk-register reporting; Loss Event Frequency instead combines Threat Event Frequency with Vulnerability.

Threat capability and control strength

Why it fails: Threat capability and control strength are not the two factors FAIR multiplies for Loss Event Frequency; control strength influences vulnerability, and capability alone is insufficient. They are tempting because both shape likelihood, but the actual composition is Threat Event Frequency and Vulnerability.

Asset value and threat actor motivation

Why it fails: Asset value and threat actor motivation sit outside FAIR's frequency branch: asset value feeds loss magnitude, and motivation is not a FAIR factor. They are tempting because both appear in broader risk discussions, but Loss Event Frequency is Threat Event Frequency combined with Vulnerability.

Data encryption

Why it fails: Encryption protects data confidentiality in transit or at rest; it does not filter or block traffic crossing the perimeter. It is tempting because it defends data, but the primary internal/external boundary is the network layer, enforced by firewalls.

Host-based security

Why it fails: Host-based security protects individual endpoints after traffic has already crossed the perimeter. It is tempting because agents harden each device, but the first boundary between internal and external networks is the network layer, where firewalls filter traffic.

Application layer

Why it fails: The application layer inspects payloads and user sessions, not the network perimeter itself. It is tempting because application firewalls add deep inspection, but the primary internal/external boundary is enforced at the network layer by firewalls and routers.

Chief Information Officer

Why it fails: The CIO sets strategic direction, not per-data classification.

Data Custodian

Why it fails: A data custodian applies the technical controls — backups, access provisioning, encryption — that the owner's classification dictates, so it cannot decide sensitivity itself. It tempts because custodians handle data daily and spot exposure, but that operational proximity is not the accountability the question asks for.

Auditor

Why it fails: An auditor independently verifies that classification was performed and controls match the assigned labels; auditing the process is not owning the decision. It tempts because auditors review classification registers and report gaps, which looks like classification work, yet their remit is assurance after the fact, not assigning value.

Security Administrator

Why it fails: A security administrator implements the controls — permissions, encryption, monitoring — that follow from a classification, rather than determining the data's value. It tempts because administrators configure the protective mechanisms tied to each label, but the accountability for deciding sensitivity rests with the business data owner.

Human Resource Security

Why it fails: Human Resource Security covers screening, terms of employment, awareness training and disciplinary process across the employment lifecycle, not entry to facilities. It is tempting because staff working in the server room fall under personnel controls, and would be correct for onboarding checks, confidentiality agreements or termination procedures.

Operations Security

Why it fails: Operations Security covers day-to-day processing, change management and malware controls, not the physical protection of facilities housing servers. It is tempting because server-room activity is operational in nature, and would be correct for controls governing backup, logging, technical vulnerability management or segregation of production duties.

Access Control

Why it fails: Access Control addresses logical access to information and systems through user registration, authentication and authorisation, not physical entry to a building or room. It is tempting because server-room entry is access of a kind, and would be correct for controlling who may log on to systems and what data they reach.

$10,000

Why it fails: ALE is SLE multiplied by ARO, so $10,000 × 0.5 = $5,000. This option simply restates the SLE, ignoring the frequency component entirely. Quoting SLE is tempting because it represents the loss from one incident, which is the correct figure when a threat is expected to occur exactly once per year (ARO of 1.0).

$20,000

Why it fails: ALE equals SLE times ARO, so $10,000 × 0.5 yields $5,000; $20,000 doubles the SLE instead of applying the 0.5 rate. It is tempting because dividing by the ARO feels intuitive, but the formula multiplies, never divides, the two figures.

$2,500

Why it fails: ALE is calculated as SLE multiplied by ARO, giving $10,000 × 0.5 = $5,000, so $2,500 halves the result incorrectly. It is tempting because halving the SLE mirrors the 0.5 ARO, but that operation misapplies the formula rather than multiplying the two values.