Select Two (Multi-Select) Questions

Communication plan for employees

Why it fails: Part of crisis management plan.

Business impact analysis results

Why it fails: BIA is part of BCP, not DRP.

Asset inventory

Why it fails: An asset inventory lists hardware and software but omits recovery strategies, RTOs, and succession or communication plans, so it alone cannot satisfy the BCP's essential components. It is tempting because assets underpin impact analysis, and it would be correct as an input when scoping risk assessments or configuration management baselines.

Vulnerability assessment

Why it fails: A vulnerability assessment identifies weaknesses for risk treatment; it does not document recovery priorities, RTOs, or alternate processing sites, so it cannot satisfy the BCP's continuity requirements. It is tempting because vulnerability findings feed risk analysis, and it would be correct when scoping security remediation or penetration-test planning rather than continuity planning.

Network diagram

Why it fails: A network diagram maps topology but records no recovery time objectives, critical process dependencies, or alternate site arrangements, so it cannot fulfil the BCP's continuity content. It is tempting because topology aids impact analysis, and it would be correct when documenting infrastructure for troubleshooting or change management.

ICMP

Why it fails: ICMP is for diagnostics, not security.

LDAP

Why it fails: LDAP is for directory services, not a VPN protocol.

SNMP

Why it fails: SNMP is for network management, not VPN security.

Disable ICMP redirects on hosts.

Why it fails: ICMP redirects concern layer-3 routing messages, not ARP, so disabling them leaves ARP cache poisoning untouched. It is tempting because ICMP redirect manipulation is a genuine attack vector, and this hardening is correct when hosts must ignore forged redirects to prevent traffic rerouting.

Use MAC address filtering on switches.

Why it fails: MAC address filtering restricts which source MACs may use a switch port, but ARP spoofing uses the attacker's own legitimate MAC with forged IP-to-MAC mappings, so filtering does not detect it. It is tempting as a Layer 2 access control, and would be correct for limiting unknown devices on a port.

Enable STP BPDU guard.

Why it fails: BPDU guard disables a port receiving spanning-tree BPDUs, defending against rogue switches and topology loops, not ARP poisoning. It is tempting because it is a Layer 2 port-security measure, and would be correct when implementing PortFast edge ports that must never participate in STP.

The email contains an attachment with a .txt extension

Why it fails: .txt files are generally safe; phishing often uses .exe, .docm, or .zip.

The email has a high-importance flag set by the sender

Why it fails: Importance flags are not reliable indicators; they can be set by anyone.

The email is sent to multiple recipients in the 'To' field

Why it fails: Legitimate emails can also be sent to multiple recipients; not a reliable indicator.

Contact law enforcement immediately.

Why it fails: Law enforcement notification follows internal containment, evidence preservation and management escalation; contacting them immediately bypasses those steps and can compromise the investigation. It is tempting because a known malicious domain suggests criminal activity, and referral is appropriate once the incident is confirmed and scoped.

Analyze the macro code in a sandbox.

Why it fails: Sandbox analysis is a later forensic examination step; immediate response requires containment actions such as isolating the workstation and blocking the malicious domain. It is tempting because macro analysis yields valuable indicators, and would be correct during the subsequent investigation phase rather than the immediate response.

Delete the phishing email from all mailboxes.

Why it fails: Deleting the email from all mailboxes destroys evidence and does not remediate the already-executed payload on the compromised workstation. It is tempting because purging a phishing message limits further clicks, and would be correct for a campaign that no recipient has yet opened.

Firewalls

Why it fails: Firewalls filter traffic between zones but do not by themselves create the isolated segments; segmentation is achieved by dividing the network into VLANs or subnets, with firewalls controlling flows between them. Firewalls tempt because they enforce policy at segment boundaries.

Intrusion Detection Systems

Why it fails: Intrusion Detection Systems monitor traffic for malicious activity; they do not partition a network into isolated segments. It is tempting because IDS is a network security control often deployed alongside segmentation, and it would be the correct choice when the requirement is detecting attacks rather than dividing the network into separate zones.

Port security

Why it fails: Port security limits MAC addresses but does not prevent ARP spoofing.

MAC address filtering

Why it fails: MAC filtering is static and easily bypassed.

Revealing technical details of the attack to the public

Why it fails: Publishing attack specifics exposes unpatched weaknesses and aids copycat intrusions, while crisis communications should deliver approved, legally vetted messaging to affected parties and regulators. Technical indicators belong in confidential threat-intelligence sharing such as an ISAC, not public disclosure during an active incident.

Deleting all logs to prevent evidence leakage

Why it fails: Destroying logs eliminates the forensic timeline needed to determine breach scope and satisfy notification duties, and may itself breach retention regulations. Log preservation is the actual requirement. Retention and legal hold policies are what an incident response plan should invoke, not deletion, which only serves attackers covering their tracks.

Authentication

Why it fails: Authentication verifies an identity's claimed credentials; it is a supporting control, not one of the CIA triad principles. It would be the correct answer if the question asked about access control mechanisms rather than core security principles.

Non-repudiation

Why it fails: Non-repudiation guarantees that a party cannot deny performing an action, typically enforced through digital signatures and audit trails. It is a security service or property, not one of the CIA triad's core principles (confidentiality, integrity, availability). It would be the correct answer when a scenario requires proving the origin or delivery of a message, such as signed transactions.

Full disk encryption

Why it fails: Full disk encryption protects data at rest on endpoints, not the network.

Antivirus software

Why it fails: Antivirus is an endpoint security control, not a network control.

Affected customers

Why it fails: Customers are notified after containment and impact assessment, not immediately; premature disclosure risks panic and legal missteps. This option is tempting because customer notification is a genuine regulatory and contractual obligation, and would be correct once forensic scope confirms which customer data was actually exfiltrated or encrypted.

All employees

Why it fails: Broadcasting to all employees before containment tips off the attacker and leaks details externally. Mass internal notification belongs to later crisis communication. It tempts because staff awareness aids phishing resistance, and would be right for a company-wide advisory after eradication, not during initial triage.

Competitors

Why it fails: Competitors have no incident-response role, no need-to-know, and no authority to act, so notifying them breaches confidentiality and could worsen the incident. It is tempting because external parties are sometimes informed after a breach, but that applies to regulators, insurers or law enforcement, not commercial rivals.

Company cafeteria menu

Why it fails: A cafeteria menu is public information, carrying no confidentiality impact, so it cannot meet restricted or top secret handling requirements. It is tempting because classification policies do cover all organisational data, and low-sensitivity items still need labelling; however, menus belong in the public tier, not the highest one.

Marketing brochures

Why it fails: Marketing brochures are deliberately published externally, so they carry no confidentiality requirement and cannot be restricted or top secret. Classification policies do cover all information assets, which makes any listed item look plausible; brochures nonetheless belong in the public tier, where disclosure causes no damage.

Privacy

Why it fails: Privacy governs appropriate handling of personal data and regulatory obligations, not one of the triad's three properties. It is tempting because confidentiality and privacy are often conflated, but privacy would be the correct focus when addressing data-protection compliance, not when identifying the CIA triad's constituent principles.

Non-repudiation

Why it fails: Non-repudiation proves an action occurred and cannot be denied, typically via digital signatures, but it is not a CIA triad property. It is tempting because it is a recognised security service, yet it would be correct when establishing legal proof of transactions, not when naming the triad's principles.

Accountability

Why it fails: Accountability assigns actions to a responsible entity through logging and auditing, supporting security but sitting outside the CIA triad's three named properties. It is tempting because it underpins governance and traceability, yet it would be correct when designing audit trails, not when naming the triad's fundamental principles.

Keep backups on the same server for easy access

Why it fails: Same-server storage means the backup is destroyed with the primary data during fire, theft or ransomware, defeating the purpose of a separate copy. Local retention is acceptable only as a fast-restore cache alongside offsite copies.

Use only tape media

Why it fails: Tape alone cannot meet recovery time objectives for frequent restores and requires drives, software and offsite rotation. Tape is a valid archival or air-gapped tier, but best practice combines it with disk or cloud copies.

Test backups annually

Why it fails: Annual testing leaves recovery unverified for up to twelve months, so media degradation or corrupted restore procedures go undetected between checks. Testing is genuinely valuable after hardware changes or before audits, but recognised practice requires periodic restore verification at intervals matched to the backup frequency and retention period, not a fixed yearly cycle.

A list of compliance standards.

Why it fails: Compliance standards are governance references, not operational incident response content; they do not tell responders whom to call or what to do during an incident. A compliance list would be relevant when preparing audit evidence or mapping controls, not as an essential element of the response plan itself.

Personal phone numbers of executives.

Why it fails: Executive personal phone numbers are neither scalable nor appropriate for incident escalation; they bypass the documented on-call and escalation chain. Such a list would be the correct choice only for a narrow crisis-communications contact sheet, not as an essential element of the incident response plan.

Contact information for all employees.

Why it fails: A full employee contact list is too broad to be actionable during an incident and does not identify who holds response roles. Contact information for the incident response team and key stakeholders is essential; a company-wide directory would be the right choice for general HR or business continuity communications.

Implement intrusion detection systems

Why it fails: Deploying intrusion detection is a detective control, whereas risk management objectives concern identifying, assessing, prioritising and treating risk. It is tempting because IDS is a recognised security capability, and it would be correct if the question asked which control supports threat detection within an environment.

Encrypt all data at rest

Why it fails: Encrypting all data at rest is a technical safeguard, not a risk management objective; the programme aims to identify, assess, treat and monitor risk to acceptable levels. It is tempting because encryption is a common compliance control, and it would be the right answer to a question asking for a data protection measure.

One-time password token

Why it fails: A one-time password token is Type 2 authentication: possession of a hardware or software device generating codes. Type 3 requires a biometric characteristic such as a fingerprint. It is tempting because OTP tokens add strong assurance beyond passwords, but possession, not inherence, is the factor.

Smart card

Why it fails: Smart cards are Type 2 authentication — something you have — not Type 3, which requires something you are, such as a fingerprint or iris scan. It is tempting because smart cards combine possession with a PIN, but the card itself remains a possession factor; biometrics alone satisfy Type 3.

Password

Why it fails: A password is Type 1 authentication — something you know — not Type 3, which requires something you are, such as a fingerprint or retina pattern. It is tempting because passwords are the most familiar credential, but knowledge is the factor being verified, not a biometric trait.

Password

Why it fails: A password is a Type 1 factor, something you know; Type 3 denotes something you are, verified through biometric characteristics such as fingerprints, retinal scans or voice patterns. A password would be correct where the question asked for Type 1 factors or for a memorised secret in multifactor authentication.

Smart card

Why it fails: A smart card is a Type 2 possession factor: you authenticate by holding the physical token. Type 3 factors verify something inherent to the person, such as a fingerprint or retina pattern. Smart cards are tempting because they often combine possession with a PIN, but the card itself remains possession, not inherence.

PIN

Why it fails: A PIN is a Type 1 factor, something you know, alongside passwords and passphrases; Type 3 covers something you are, such as fingerprints, iris patterns or facial geometry. A PIN would be correct where the question asked for Type 1 factors or for a knowledge-based component of multifactor authentication.

Risk duplication

Why it fails: NIST SP 800-30 defines risk treatment as accept, avoid, mitigate (reduce) and transfer (share); duplication is not among them, since copying a risk does not alter its likelihood or impact. It is tempting because duplicating controls or systems sounds protective, but redundancy is a mitigation technique, not a treatment category.

Risk identification

Why it fails: Identification is the first step of the risk management process, occurring before treatment; NIST SP 800-30 treatment options are accept, avoid, mitigate and transfer. It is tempting because identification is a genuine risk management activity, but it produces the risk register rather than selecting a response to an assessed risk.