Select Two (Multi-Select) Questions

Disable the rule entirely

Why wrong: Disabling the rule entirely eliminates the alert noise problem by also eliminating all detection capability, including for real brute-force attacks — the opposite of the stated goal, which is to reduce false positives while still catching genuine attacks. A rule that never fires isn't tuned, it's removed, taking away the SIEM's ability to flag credential-stuffing or password-spraying activity entirely.

Increase the alert severity to critical for all failed logins

Why wrong: Raising every failed-login alert to critical severity changes how alerts are prioritized in the queue but does nothing to reduce the actual number of alerts being generated — the SIEM still fires on every single failure, so the analyst team remains overwhelmed by volume. It may even worsen things by burying genuinely urgent alerts among a flood of newly-critical low-value ones.

Add a correlation rule to trigger on successful login after multiple failures

Why wrong: A correlation rule for a successful login after multiple failures is a genuinely useful detection for catching brute-force attempts that ultimately succeed, but it's an additional detection layer, not a noise-reduction technique — it doesn't touch the volume of individual failed-login alerts already overwhelming the team, so on its own it doesn't solve the stated tuning problem.

Setting resource limits on containers

Why wrong: Setting resource limits on containers constrains CPU, memory, and I/O usage, ensuring that a single compromised or misbehaving container cannot starve the host or neighboring containers of resources. This is a proactive hardening measure that mitigates denial-of-service and resource-exhaustion attacks. Far from being a vulnerability, it is a required security control in multi-tenant container environments.

Configuring network policies to restrict traffic

Why wrong: Configuring network policies to restrict traffic enforces a least-privilege model by defining which containers or pods can communicate with each other and with external endpoints. Without such policies, all inter-container traffic is typically allowed, expanding the blast radius of a compromise. Because this reduces the attack surface and limits lateral movement, it is a security best practice, not a risk.

Using read-only root filesystems

Why wrong: Using read-only root filesystems prevents any process inside the container from writing to the container image's root filesystem layer, which stops attackers from dropping malware or modifying critical executables and configuration files. It forces any required writes to be done through explicit ephemeral volumes, maintaining filesystem integrity. This is a well-known defensive hardening technique that reduces the impact of a compromised container, so it is not a vulnerability.

DNS responses with NXDOMAIN for most queries

Why wrong: A steady stream of NXDOMAIN responses means the queried hostnames do not exist, which reflects failing lookups (typos, scans, or misconfigured clients) rather than successful data transfer. For tunneling to work, the attacker must authoritatively answer every crafted subdomain query with a valid response, so the answer would be NOERROR and contain a meaningful payload, not a 'non-existent domain' error. Consequently, a high NXDOMAIN rate is often a sign of DNS reconnaissance or a DDoS amplification, not covert exfiltration.

Use of standard A record queries

Why wrong: Standard A record queries—which map hostnames to IPv4 addresses—are the backbone of legitimate DNS traffic, so their mere presence is not an anomaly and cannot by itself indicate tunneling. Even if an attacker were to use A queries for covert communication by encoding data into the query name, the encoding is typically placed in the subdomain labels, not the record type, and that pattern would be visible as unusual label entropy or length, not as the use of A records. Therefore, observing typical A queries actually describes baseline behavior and provides no discrimination between malicious and benign activity.

Repeated failed logins to multiple hosts

Why wrong: Repeated failed logins to multiple hosts may indicate brute-force attempts or password spraying, but they are pre-authentication failures, not evidence of an established lateral movement session. Once an attacker gains valid credentials, lateral movement often appears as successful logins or SMB connections rather than recurring failures, so this event is too noisy and ambiguous for a horizontal movement detection rule.

High volume of DNS queries

Why wrong: A high volume of DNS queries is typically associated with malware beaconing, domain generation algorithms, or reconnaissance, yet it does not involve the SMB protocol (ports 445/139) that Windows lateral movement relies on for file shares, named pipes, and remote administration. Lateral movement between workstations leverages direct authenticated SMB sessions, whereas DNS is a separate name-resolution service; correlating DNS volume alone would generate many false positives from legitimate internet activity.

Unusual outbound connections on port 443

Why wrong: Unusual outbound connections on port 443 are typically HTTPS web traffic and do not represent the native SMB protocol used in lateral movement. While an attacker could tunnel SMB over port 443 (e.g., via SOCKS proxies or port forwarding), standard SMB lateral movement occurs on ports 445/139, and monitoring for admin share access or SMB peer traffic is much more direct. Outbound 443 anomalies are more often associated with command-and-control communication or data exfiltration rather than a moving between hosts via Windows file services.

Windows Event Logs for service creation

Why wrong: Windows Event Logs for service creation are indeed a valuable persistence detection source, with Event ID 7045 logging new service installations, but this activity typically results from commands like `sc create` or the Service Control Manager API, not a `reg add` command. Since the observed command targets a registry Run key rather than creating a service, checking service creation logs would not reveal the persistence mechanism used by this attacker. However, defenders should still review these logs for secondary persistence methods, as attackers often deploy multiple techniques.

Browser history

Why wrong: Browser history is completely unrelated to the command-line telemetry indicating registry persistence; it records web browsing activity such as visited URLs and search queries, which could reveal C2 infrastructure or download sources but says nothing about the registry modification in question. A threat hunter would not look at browser history to confirm or deny persistence via a Run key, and doing so would waste time while the immediate persistence vector remains unchecked. This option is a distraction from the relevant endpoint forensics.

Network connections

Why wrong: Network connections are not directly related to registry persistence; examining network connections (e.g., netstat or network flow logs) would reveal active C2 communication or data exfiltration, which is a post-persistence behavior, not the persistence mechanism itself. The `reg add` command is a local, atomic operation that does not involve network sockets, so checking connections would not help verify the Run key change. While network telemetry is useful for detecting the attacker's later actions, it is not the immediate priority for confirming this persistence technique.

Broken Access Control

Why wrong: Broken Access Control is a separate vulnerability category, not an injection flaw. It arises when an application fails to enforce restrictions on what authenticated users can access or do, such as viewing other users' private data or performing unauthorized functions. Unlike injection attacks, it does not involve sending malicious interpretable code; instead, it relies on manipulating requests, URLs, or client-side state to bypass authorization checks.

Security Misconfiguration

Why wrong: Security Misconfiguration is a separate vulnerability category and not an injection flaw. It results from insecure default configurations, incomplete setups, open cloud storage, verbose error messages, or unnecessary enabled features. This category does not involve injecting malicious input into an interpreter; rather, it happens because the application or its environment is not securely configured, leaving doors open for various types of attacks.

-encode

Why wrong: Encodes a file to base64; typically not for downloading.

-verify

Why wrong: Verifies a certificate chain; legitimate use.

OpenVAS

Why wrong: OpenVAS is a network vulnerability scanner.

Burp Suite

Why wrong: Burp Suite is for web application testing.

Remove all unnecessary packages and services

Why wrong: Removing all unnecessary packages and services is a sound hardening practice that reduces the attack surface, but it is typically categorized as Level 2 in the CIS Benchmarks. This is because the removal process can break expected functionality if an application relies on a particular package or daemon, requiring thorough business impact analysis and testing. Level 1 controls are intended to be low-impact, universally applicable security settings, so this action does not qualify as a Level 1 baseline.

Enable mandatory access control (SELinux) in enforcing mode

Why wrong: Enabling SELinux in enforcing mode provides strong mandatory access control, but it is commonly relegated to Level 2 because enforcing mode can deny legitimate application operations when policies are not fully tuned, potentially causing service outages. This requires significant policy customization and testing for each environment, making it disruptive for organizations not already prepared. A Level 1 control must be deployable with minimal operational friction, which enforcing mode does not always offer, so it is not the correct choice here.

Configure audit rules for file permission changes

Why wrong: Configuring audit rules to monitor file permission changes is a powerful forensic control, but it is generally assigned to Level 2 in the CIS Benchmarks. The reason is that extensive audit logging can generate large volumes of data, increasing storage costs and potentially causing performance degradation on busy systems. Additionally, the rule sets are highly site-specific—organizations may need to tailor them to their own compliance requirements—so they are not a uniform, low-impact Level 1 setting.

Conduct a tabletop exercise for the incident response team.

Why wrong: Tabletop exercises are an evaluation or training mechanism for incident response processes, roles, and communication flows, not a method for modifying detection content. Running a dry-run with the team may surface procedural gaps, such as unclear escalation paths, but it does not add or tune any signature, YARA rule, or SIEM correlation logic. Because the goal is to improve human readiness rather than defensive sensors, it would not have directly detected the actual ransomware on the network.

Increase the frequency of vulnerability scans.

Why wrong: Vulnerability scanning is a proactive posture activity that identifies missing patches, weak configurations, or known CVEs, but it is not a detection-rule update. Even if the ransomware exploited a known vulnerability, the scanner does not write indicators or behavioral patterns into the SIEM, EDR, or endpoint protection. Increasing scan frequency might reveal the attack surface before exploitation, but it provides no mechanism to detect the specific ransomware's files, hashes, or attacker TTPs during an active intrusion.

Share IOCs with external threat intelligence platforms.

Why wrong: Sharing IOCs with external threat intelligence platforms (e.g., MISP, ITX) is a community-based defense action that benefits other organizations by publishing indicators like IPs, domains, and hashes, but it does not alter the incident team's own detection infrastructure. The action is outward-bound; until an external feed is imported back into the SIEM or EDR and configured as a detection source, it has no effect on internal monitoring. Moreover, relying solely on blocklists after an incident is often insufficient because the same TTPs may be reused with new IOCs, so this step alone is not a direct detection-rule update.

Network topology diagrams

Why wrong: Network topology diagrams reveal the arrangement of subnets, firewalls, and hosts, which helps auditors understand the scope of the environment, but they do not capture vulnerability findings, severity ratings, or remediation timelines. Compliance audits for vulnerability management demand evidence of the ongoing detection and mitigation process, such as scan outputs or patch records, not just architectural blueprints. Without timestamps or vulnerability identifiers, these diagrams cannot substantiate that the organization has actively identified and addressed known weaknesses.

Employee training logs

Why wrong: Employee training logs document security awareness sessions and phishing simulations, yet they fail to demonstrate the technical lifecycle of vulnerability management, including discovery, risk ranking, and patch deployment. Auditors seeking compliance with vulnerability management requirements need artifacts that show system-level scanning and remediation, not personnel attendance records. Training records might support a governance framework, but they are not a substitute for scan reports or change management evidence.

Incident response playbooks

Why wrong: Incident response playbooks provide step-by-step procedures for containing and eradicating threats during an active breach, but they are not records of audit-driven vulnerability management activities. These documents are static and only become relevant when something goes wrong, whereas vulnerability management requires periodic, evidence-based proof of scanning and patching. While they indicate a mature security operations capability, they cannot demonstrate that the organization has been consistently identifying and fixing vulnerabilities across its environment.

Disabling the user's network account immediately

Why wrong: This is a containment step, not evidence preservation.

Interviewing the user about their activities

Why wrong: Interviews are part of investigation but not evidence preservation.

Operational impact

Why wrong: Operational impact relates to the day-to-day functioning of business processes, such as system downtime or productivity losses. While these are tangible consequences, they are too granular for board-level discussions where the focus is on strategic and financial outcomes. At the board level, operational details are typically aggregated into higher-level risk metrics that tie directly to organizational objectives.

Technical impact

Why wrong: Technical impact focuses on system-specific details like patch status, configuration flaws, or exploit techniques. This level of detail is not appropriate for board-level communication, as it does not translate into business consequences. The analyst must translate technical findings into business risk language, emphasizing potential damage to operations, finances, or compliance rather than the underlying technical mechanisms.

Whether the storage account name is short

Why wrong: The length or specific naming convention of a storage account provides no inherent security or protection against public exposure. Public access is determined by explicit access control lists (ACLs), bucket policies, or account-level settings, not by the arbitrary string used for identification. A short name does not make an object more or less vulnerable to misconfiguration, as security relies on proper policy enforcement.

Whether the administrator uses dark mode

Why wrong: An administrator's personal user interface preferences, such as enabling dark mode, are purely aesthetic and have no bearing on the underlying security posture or public accessibility of cloud resources. Security configurations are managed through specific IAM policies, bucket policies, and network access controls, which operate independently of how the console is visually rendered. UI settings do not influence effective permissions or resource exposure.

Suspend the employee's accounts outright.

Why wrong: Suspending an employee's accounts outright is an overly aggressive and premature action based solely on suspicion. Such a drastic step could immediately alert the suspected insider, potentially leading to the destruction of evidence or further malicious actions from alternative vectors. Furthermore, it carries significant human resources implications if the initial suspicion proves unfounded, causing unnecessary organizational disruption.

Immediately notify law enforcement.

Why wrong: Immediately notifying law enforcement is premature when an insider threat is only suspected and not yet confirmed through a thorough internal investigation. Law enforcement involvement is typically reserved for confirmed criminal activity or severe data breaches after internal evidence collection and analysis. Premature notification can complicate internal incident response processes, potentially hinder the investigation, and unnecessarily strain organizational resources.

Confront the employee about the behavior.

Why wrong: Confronting the employee about their behavior at this early stage of suspicion is highly inadvisable and counterproductive to an effective investigation. Direct engagement could immediately alert the suspected insider, prompting them to destroy critical digital evidence, escalate their malicious activities, or even retaliate against the organization. Incident response best practices dictate covert evidence collection and confirmation before any direct interaction with the subject.

Individual performance evaluations of team members

Why wrong: A post-incident review, particularly the "lessons learned" phase, is designed to improve organizational processes and procedures, not to conduct individual performance evaluations. Focusing on individual performance can foster a culture of blame, hindering open communication and honest assessment of systemic failures. The objective is to identify systemic weaknesses and enhance future incident response capabilities, not to discipline personnel.

Legal liability of the organization

Why wrong: While legal implications are a significant consequence of a data breach, determining the organization's legal liability is typically handled by legal counsel and is distinct from the technical post-incident review process. The primary goal of the technical review is to understand how the breach occurred and what can be done to prevent recurrence, not to assess legal culpability or prepare for litigation. Mixing these objectives can compromise the objectivity of the technical analysis.

Publish a public notice in the local newspaper

Why wrong: Publishing a public notice in a local newspaper is not a primary or standalone requirement under GDPR for data breach notification. While Article 34 allows for public communication if direct notification to data subjects is not feasible or would involve disproportionate effort, it is typically a last resort or supplementary measure. GDPR primarily emphasizes direct, individualized notification to affected data subjects when high risk is present.

Notify law enforcement within 24 hours

Why wrong: The GDPR does not specifically mandate notifying law enforcement within a 24-hour timeframe for a data breach. Its primary focus for external notification is the relevant supervisory authority and, if applicable, the affected data subjects. While other national laws or sector-specific regulations might require law enforcement notification, this is not a universal GDPR provision, and the 24-hour period is not specified by GDPR.

Only scanning ICMP echo replies

Why wrong: ICMP echo replies only confirm that a host is reachable on the network and responding to ping requests; this protocol carries no application or package-layer data whatsoever, so it can never be used to enumerate installed software versions or identify missing patches, regardless of how the scan is otherwise configured.

Changing server hostnames randomly

Why wrong: Randomizing server hostnames changes only a cosmetic network identifier used for DNS and inventory labeling; it does not alter what packages are installed, what permissions the scanner account holds, or what protocol the scan uses, so it has no effect on the accuracy of vulnerability findings.

Creating a forensic image of the infected systems for later analysis.

Why wrong: While creating a forensic image is essential for preserving evidence and supporting post-incident analysis, it does nothing to stop the malware from continuing to communicate or spread across the network. Containment must occur first to halt active propagation; imaging is a preservation step, not a containment action. In this scenario, it is a wrong answer because it fails to address the immediate threat.

Identifying and patching the vulnerability exploited by the malware.

Why wrong: Identifying and patching the exploited vulnerability is part of eradication and recovery, not immediate containment. Patching requires vulnerability analysis, patch availability, and deployment, during which malware can continue spreading; it also does not remediate systems already compromised. Thus, it is not an appropriate initial containment action for an active outbreak.

Notifying law enforcement agencies about the incident.

Why wrong: Notifying law enforcement is a legal and procedural obligation that may be required by policy, but it is not a technical containment action. It has no effect on malware execution, communication, or spread, and should occur in accordance with the incident response plan after containment is initiated. Consequently, it is incorrect in the context of immediate incident containment.

Raw CVSS scores for all vulnerabilities

Why wrong: Raw CVSS scores are quantitative metrics that require contextual interpretation; a list of scores without asset criticality, threat intel, or business impact is meaningless to executives. Aggregating and prioritizing scores is the analyst's job, and dumping raw numbers shifts that burden to a non-technical audience. An executive summary should instead present a risk-ranked view that accounts for compensating controls and organizational context.

Detailed technical description of each vulnerability

Why wrong: Detailed technical descriptions expose attack paths, dependencies, and exploit mechanics, which are essential for remediation teams but not for executive decision-making. Executives need the technical severity translated into business terms—legal exposure, financial impact, or regulatory compliance—not the inner workings of a buffer overflow or misconfigured S3 bucket. Including such granularity consumes the reader's attention and obscures the strategic messages that require governance action.

Network topology diagrams

Why wrong: Network topology diagrams illustrate where vulnerabilities reside and how attackers might propagate, but they are operational tools for IT staff to plan mitigations, not strategic decision aids for management. An executive summary should convey the risk level, resource allocation, and required approvals, not segment layout or firewall placement. Placing these diagrams in an appendix supports the technical appendix without diluting the executive-appropriate narrative.