Select Two (Multi-Select) Questions

Writing code

Why it fails: Writing code is a software development activity governed by secure coding standards, not a governance function itself. Governance establishes the policies, roles and assurance mechanisms that constrain how code is written. Coding would be correct if the question asked which activity secure development policy governs, not what governance performs.

Wiring network cables

Why it fails: Wiring network cables is physical infrastructure implementation, performed by network engineers under change control. Governance defines acceptable use, risk appetite and oversight structures rather than installing cabling. Cabling would be the right answer if the question concerned who executes approved infrastructure changes, not programme-level direction.

Patching server OS

Why it fails: Patching server OS is an operational vulnerability-management task executed by IT teams, not a governance function. Governance sets policy, assigns risk ownership and measures compliance. Patching would be the correct answer if the question asked who implements the controls that governance mandates, rather than what governance itself does.

Web proxy logs showing internet browsing activity

Why it fails: Web proxy logs record outbound HTTP and HTTPS requests, not internal file server access. They may show whether data was uploaded externally, but they do not tie a user to specific file access events on the file server. They are not a priority for correlating user activity with file access.

Firewall logs showing allowed and denied connections between network segments

Why it fails: Firewall logs indicate network-level connections but do not identify which user accessed which file. They can show that a workstation connected to the file server, but without user identity or object-level detail, they cannot establish unauthorized file access by an insider.

File server system logs showing disk errors and hardware faults

Why it fails: System logs on the file server record operating system and hardware events such as disk errors, not user file access. They do not contain user account information or file access details, so they cannot correlate a user to unauthorized file access. They are relevant for availability issues, not insider threat investigation.

Registry modification

Why it fails: Registry modification is a persistence or defence-evasion technique, executed after a foothold exists, so it cannot be initial access. It is tempting because registry writes often accompany malware installation, and in a scenario asking about persistence or privilege escalation, registry modification would be the correct classification.

Screen capture

Why it fails: Screen capture is a collection technique, gathering data from a host after compromise, so it is not an initial access tactic. It is tempting because screen capture frequently appears in intrusion reports alongside the initial access vector, and in a question about collection it would be the correct answer.

Network scanning

Why it fails: Network scanning is a Discovery technique, mapping reachable hosts and services before any access attempt; Initial Access requires an exploitation or delivery action such as phishing or valid accounts. Discovery is tempting here because scanning often precedes intrusion, but it gathers information rather than establishing the foothold.

Change all company Wi-Fi passwords

Why it fails: Rotating Wi-Fi passwords does not address the compromised PII, its storage, or the affected accounts, and disrupts the whole company. It is tempting because credential rotation is a standard containment step, and it would be correct if the incident involved a breached network or wireless credential.

Post a message on the company intranet

Why it fails: An intranet post broadcasts the incident to all staff, widening exposure of the PII rather than containing it. It is tempting because internal communications are routine during incidents, and an intranet notice would be appropriate for a general service outage carrying no personal data.

Delete all user databases

Why it fails: Deleting user databases destroys the evidence and business records an investigation needs, and does not contain the exposure. It tempts as an apparent way to purge sensitive data, but PII incident response requires preserving logs, scoping affected records and notifying according to policy.

Creating a scheduled task to run a payload at logon

Why it fails: Creating a scheduled task is a Persistence technique (T1053 Scheduled Task/Job), not Discovery. It ensures the adversary maintains access. While it may be part of an attack chain, it does not gather information about the environment; it establishes a foothold. Therefore, it does not fit the Discovery tactic.

Using 'wevtutil cl' to clear Windows event logs

Why it fails: 'wevtutil cl' clears event logs, which is a Defense Evasion technique (T1070 Indicator Removal on Host). It is used to hide traces of adversary activity, not to discover information. Discovery involves actively gathering details about the system or network, whereas this action removes evidence, making it a different tactic.

Dumping LSASS memory to extract credentials

Why it fails: Dumping LSASS memory is a Credential Access technique (T1003 OS Credential Dumping). It is used to steal credentials, not to discover information about the environment. While it may yield valuable data, it is categorized under Credential Access because the primary goal is obtaining credentials, not reconnaissance.

DHCP lease logs

Why it fails: DHCP lease logs map IP addresses to MAC addresses at assignment time, but omit session content, destination reputation and authentication events. They are tempting because they are network logs and can attribute an address to a host, and would be correct when correlating an IP to a device during forensic timeline reconstruction.

Printer queue logs

Why it fails: Printer queue logs record spooled document jobs and device status, containing no network session, flow or authentication data. They are tempting because they are logs and can reveal document handling, and would be correct when investigating unauthorised printing or document leakage rather than a network-borne breach.

The specific hardware temperature of the server.

Why it fails: Hardware temperature is infrastructure telemetry, not a database audit event, so it neither evidences compliance nor reveals malicious activity such as privilege escalation or data exfiltration. It is tempting because thermal anomalies can precede outages; that metric belongs in host monitoring, not the database security log.

The number of active user sessions in the connection pool.

Why it fails: Connection-pool session counts are capacity and performance metrics, not auditable security events, so they cannot demonstrate compliance or expose malicious activity like failed logins or schema changes. It is tempting because session spikes can indicate abuse; that signal belongs in performance monitoring, not the security audit trail.

Enabling promiscuous mode on all switches to monitor traffic

Why it fails: Promiscuous mode allows a switch port to see all traffic, which is useful for monitoring but can be a security risk if misused. It does not contribute to segmentation; in fact, it can break isolation by allowing a port to capture traffic from other segments. It is not a component of secure segmentation.

Implementing a flat network topology to simplify management

Why it fails: A flat network topology is the opposite of segmentation. It allows unrestricted communication between all devices, increasing the attack surface and enabling lateral movement. This would undermine the goal of protecting critical assets. Flat networks are not a component of secure segmentation.

Relying solely on endpoint antivirus for protection

Why it fails: Endpoint antivirus is important but does not provide network segmentation. It cannot prevent lateral movement between segments if the network is flat. A secure segmented design requires network-level controls, not just endpoint protection. Antivirus alone is insufficient for segmentation.

Changing the administrator's wallpaper to the company logo.

Why it fails: Endpoint hardening concerns the web service's configuration, patches, exposed ports and file permissions. Wallpaper branding is cosmetic desktop personalisation with no security effect on the service. It tempts candidates because corporate imaging standards are sometimes grouped under hardening checklists, yet visual customisation alters no attack surface.

Configuring the server to auto-restart every 10 minutes.

Why it fails: Endpoint hardening reduces attack surface through patching, disabling unused services, least-privilege permissions and secure configuration. Scheduled auto-restarts merely mask instability and interrupt service without closing any vulnerability. It tempts administrators because restarting clears memory-resident threats temporarily, but that is incident response, not hardening.

Replacing the server's RAM with larger capacity sticks.

Why it fails: Endpoint hardening addresses software configuration, patch levels, service exposure and access controls on the web service. Adding RAM changes hardware capacity, leaving vulnerabilities, default credentials and unnecessary modules untouched. It tempts candidates because performance tuning is often bundled with server maintenance, yet memory upgrades deliver no security control.

Keylogging

Why it fails: Keylogging captures credentials or keystrokes on a compromised host, which is collection rather than exfiltration. It is tempting because stolen credentials enable later data theft, but exfiltration techniques move data out of the environment, such as over C2 channels or physical media.

File system enumeration

Why it fails: File system enumeration lists directories and files to identify targets; it is discovery, not exfiltration. It is tempting because it precedes data theft, but exfiltration techniques actually transfer data externally, such as through command-and-control channels or removable media.

Increase the minimum password length for all accounts to 20 characters

Why it fails: A longer minimum password length strengthens resistance to offline cracking and guessing, which is valuable. However, it does not limit what a compromised privileged credential can do once stolen; the attacker still holds valid administrative rights. Length alone therefore does not reduce the blast radius, which is the specific objective in this scenario.

Deploy a signature-based antivirus agent on every server

Why it fails: Signature-based antivirus helps detect known malware but does nothing to bound the authority of a valid administrative credential. If an attacker authenticates legitimately with stolen privileged credentials, the antivirus agent sees authorized activity and the attacker retains full administrative reach, so this control does not limit the blast radius of the compromised account.

Enable full-disk encryption on all administrator workstations

Why it fails: Full-disk encryption protects data at rest if a device is lost or stolen, and it is a sound baseline control. It does not constrain the privileges attached to a compromised account, so an attacker who steals credentials from a running, unlocked system still gains the same administrative reach. It therefore fails to address the blast-radius objective directly.

Background checks

Why it fails: Background checks are an administrative control, screening personnel before employment rather than restricting access through system configuration. It is tempting because vetting reduces insider threat, and it would be correct when classifying administrative controls such as onboarding screening, training and separation-of-duties policies.

Security policy documentation

Why it fails: Policy documentation is an administrative control, governing behaviour through written rules rather than enforcing restrictions in code or configuration. It is tempting because policies underpin every security programme, and it would be correct when classifying administrative controls such as standards, procedures and guidelines.

Guard patrol

Why it fails: Guard patrol is a physical control, relying on human presence and deterrence rather than automated enforcement within systems. It is tempting because patrols directly prevent intrusion, and it would be correct when classifying physical controls such as fences, locks, lighting and security personnel.

Firewall logs

Why it fails: Firewall logs record allowed or denied network connections based on IP addresses and ports. They do not provide user-level or application-level details, such as which user clicked a link. While they might show a connection to the malicious IP, they cannot distinguish between a user-initiated click and other automated traffic. Therefore, they are not directly useful for this purpose.

Domain Name System (DNS) logs

Why it fails: DNS logs show domain name resolutions but do not indicate which user or process initiated the query. While they can reveal that a lookup for the malicious domain occurred, they cannot directly attribute it to a specific user clicking the link in the email. Without user context, DNS logs alone are insufficient to confirm user interaction, though they can be used as a supporting indicator.

Email gateway logs

Why it fails: Email gateway logs show whether the email was delivered, blocked, or quarantined, and may include attachment or URL details. However, they do not record user interactions such as clicking a link. While they are useful for understanding the initial delivery, they cannot confirm whether a user clicked the link, so they are not directly useful for that specific determination.

Net present value (NPV) of the CRM investment

Why it fails: NPV is a financial metric used to evaluate the profitability of an investment over time by discounting future cash flows. It is not a factor in qualitative risk assessment and does not describe threat likelihood or business impact from a security perspective. Including NPV would confuse financial appraisal with risk prioritization and is irrelevant to building a risk matrix.

Return on security investment (ROSI) percentage

Why it fails: ROSI is a quantitative measure that compares the monetary benefits of a security control against its cost. It depends on financial estimates such as ALE and control cost, so it belongs to quantitative analysis. The scenario calls for qualitative prioritization without monetary values, making ROSI unsuitable as a matrix factor for ranking risks in this assessment.

Annualized loss expectancy (ALE) in monetary terms

Why it fails: ALE is a quantitative metric calculated by multiplying single loss expectancy by annualized rate of occurrence. Because the scenario explicitly seeks to prioritize risks without assigning monetary values, ALE is inappropriate. Using ALE would require financial estimates and move the assessment toward a quantitative approach, contradicting the stated goal of a qualitative matrix.

It is kept confidential and shared only with the security operations team

Why it fails: Risk appetite must be communicated broadly so that business units, developers, and vendors can align decisions to it. Restricting it to security operations prevents the rest of the organization from making risk-consistent choices and undermines governance. Confidentiality of the statement itself is not a characteristic of effectiveness; transparency within the organization is.

It eliminates all residual risk across clinical and administrative systems

Why it fails: Eliminating all residual risk is impossible and contradicts the concept of appetite, which defines how much risk the organization is willing to retain. Pursuing zero residual risk would halt clinical operations and is economically unfeasible. Risk appetite guides acceptable trade-offs; it does not demand the absence of risk.

It is revised annually regardless of changes in business strategy

Why it fails: A fixed annual revision cycle ignores the reality that appetite should shift with strategy, threat landscape, and regulatory changes. For a hospital, a merger, a new telehealth service, or updated HIPAA guidance could all warrant immediate revision. Effectiveness depends on review triggered by material change, not on a rigid calendar interval.

Enabling automatic operating system updates that install immediately without testing

Why it fails: Immediate, untested OS updates on ICS engineering workstations risk breaking vendor-supported software and disrupting production. ICS environments typically require staged patch testing because HMI and engineering applications are often certified only against specific OS builds. While patching is important, uncontrolled automatic updates are inappropriate for operational technology where availability and vendor compatibility constrain change windows.

Installing consumer antivirus software with aggressive heuristic scanning on all engineering hosts

Why it fails: Consumer antivirus with aggressive heuristics can quarantine legitimate engineering or HMI binaries and cause production outages in ICS environments. Industrial deployments require vendor-validated endpoint protection with exclusions for control software, not off-the-shelf consumer products. This option introduces availability risk and is not a sound hardening control for workstations that directly interface with PLCs on the plant floor.

Allowing engineers to install any utility from the internet to troubleshoot PLC connectivity

Why it fails: Permitting arbitrary internet downloads directly contradicts attack surface reduction and introduces unvetted code onto trusted engineering hosts. Troubleshooting utilities should come from an approved repository and be tested before deployment. This practice also undermines allowlisting and can introduce malware into a segmented ICS network, so it must not be part of a hardened baseline.

Apply the same access control policy used for public marketing collateral to simplify administration.

Why it fails: Public collateral is intentionally open, so reusing its access policy would expose sensitive contracts and HR records to broad audiences. Classification tiers exist precisely to differentiate handling requirements, and collapsing them defeats the purpose. This action directly violates the principle that controls scale with sensitivity, making it inappropriate for the highest tier.

Allow users to store local copies on unmanaged endpoints to improve productivity during contract negotiations.

Why it fails: Unmanaged endpoints lack the encryption, patching, and monitoring that the top tier requires, so local copies create uncontrolled duplicates that are difficult to track or erase. This expands the attack surface and undermines data retention and privacy obligations. Productivity convenience does not justify removing handling controls from the most sensitive data.

Publish the classification labels in a public wiki so all staff understand how data is tagged.

Why it fails: Publishing the label scheme itself is not harmful, but it does not constitute a handling control for the sensitive data and does nothing to protect contracts or HR records. Awareness material supports the program without securing the assets. Treating documentation as a top-tier control confuses communication with enforcement, so it does not meet the requirement.

Upgrade the user's OS

Why it fails: Not a direct eradication action for account compromise.

Block the user's physical building access

Why it fails: Securing a compromised account centres on identity controls: password reset, session and token revocation, and MFA re-enrolment; building access is a physical control unrelated to the account compromise. It is tempting because an attacker with credentials may also have physical presence, but that is handled by the physical security team, not account eradication.

Delete the user's home directory

Why it fails: Eradication requires disabling or resetting the compromised account, revoking active sessions and tokens, and rotating credentials; deleting the home directory destroys forensic evidence and business data while leaving the identity itself intact. It is tempting because removing the account's data feels like thorough cleanup, but it is destructive and reversible only from backup.

Use a web browser on the analyst's workstation to visit the URL and inspect the page content.

Why it fails: Visiting the URL directly on a workstation risks compromising the analyst's system if the site exploits a browser vulnerability or downloads malware. This action violates safe analysis practices. Even with updated browsers, zero-day exploits or drive-by downloads can occur. The analyst should never interact with a suspicious URL from a production system.

Perform a WHOIS lookup to obtain the registrar and registrant details of the domain.

Why it fails: WHOIS provides registration information such as registrar, creation date, and sometimes registrant contact details. While useful for context, it does not reveal whether the URL hosts malicious content or what payload it delivers. WHOIS alone is insufficient for dynamic analysis and does not safely determine the URL's behavior.

Run a command-line tool like curl to download the URL's content to the analyst's workstation for inspection.

Why it fails: Using curl to download content to a workstation can introduce malware if the file is executed or if the download triggers an exploit. While curl itself is safe for retrieving data, saving and inspecting the content on a production system poses a risk. This method lacks the isolation and behavioral recording of a sandbox.

Building maintenance schedules

Why it fails: Building maintenance schedules describe facility operations and contain no indicators of compromise or adversary tactics, so they cannot populate threat intelligence feeds. They are tempting because internal operational data can inform risk assessments, but maintenance schedules would be correct only for physical security planning, not cyber incident detection.

Internal employee social media posts

Why it fails: Employee social media posts are personal content, not curated indicators of compromise or adversary infrastructure, so they cannot populate threat intelligence feeds. They are tempting because OSINT includes social media, but employee posts would be correct only for insider-threat monitoring, not external threat feed generation.

Public weather reports

Why it fails: Weather reports contain meteorological data with no indicators of compromise, adversary infrastructure, or vulnerabilities, so they cannot populate threat intelligence. They are tempting because feeds aggregate external data sources, but weather data would be correct only for operational planning, not incident detection.