Scenario practice questions

Deploy a Web Application Firewall (WAF) with SQL injection signatures.

Why it fails: A WAF can block known SQL injection patterns, but it is a reactive measure that can be bypassed with obfuscation or new techniques. It does not fix the underlying vulnerability in the application code. While it adds a layer of defense, it should not be the primary mitigation. The most effective solution is to address the root cause by using parameterized queries.

Implement strict input validation to allow only alphanumeric characters.

Why it fails: Strict input validation can reduce the attack surface, but it is not foolproof and can break legitimate functionality if not carefully designed. Attackers can sometimes bypass validation using encoding or alternative characters. Moreover, it does not address the root cause if the application still concatenates input into SQL queries. Parameterized queries are a more robust solution.

Encode all user input using HTML entity encoding before storing in the database.

Why it fails: HTML entity encoding is used to prevent cross-site scripting (XSS) when outputting data to HTML contexts, not to prevent SQL injection. Applying it before database storage would not stop SQL injection because the database interprets encoded characters as part of the SQL syntax. It is the wrong layer of defense for this attack type.

A stateless packet-filtering router that evaluates each packet independently against ACLs.

Why it fails: Stateless packet filtering does not maintain connection state, so it cannot perform stateful connection tracking. It evaluates each packet in isolation against ACLs and often requires rules for both directions of a flow. The description explicitly includes stateful connection tracking and NAT, which go beyond stateless filtering. Therefore, a stateless packet-filtering router does not match the described capabilities.

A next-generation firewall that performs full application-layer inspection and user identity mapping.

Why it fails: A next-generation firewall does stateful tracking and NAT, but it also performs deep application inspection, application identification, and often user identity mapping. The scenario explicitly states that deep application inspection is not provided, so an NGFW exceeds the described capabilities. Although an NGFW could be placed in that position, the description points to a simpler stateful firewall rather than a full application-aware platform.

A web proxy that terminates HTTP and HTTPS connections and enforces content policies.

Why it fails: A web proxy operates at the application layer, terminates client connections, and enforces content or URL policies. It does not typically provide general-purpose stateful connection tracking for all protocols or network address translation for arbitrary traffic. The description mentions NAT and stateful connection tracking without application inspection, which is not the role of a web proxy. Therefore, this device type does not match the scenario.

head -n 20 /var/log/auth.log

Why it fails: The head command displays the beginning of a file. It is not suitable for monitoring real-time logs because it does not update as new lines are written. Using head would only show historical, static data from the start of the file, failing to capture ongoing security events.

cat /var/log/auth.log | grep -v 'accepted'

Why it fails: The cat command outputs the entire file content at once and terminates. It does not provide real-time updates. While piping to grep is useful for filtering text, it provides a static snapshot of the file's contents at the moment the command was executed, missing any subsequent log entries.

more /var/log/auth.log

Why it fails: The more command is a legacy pager that displays file contents page-by-page. It lacks the functionality to follow a file as it grows. Once the end of the file is reached, it exits, making it unsuitable for the active observation required during security troubleshooting or real-time log analysis.

Implementing full-disk encryption on the EHR database servers

Why it fails: Full-disk encryption protects data at rest if the physical disk is stolen, but it does not detect unauthorized modification of records while the system is running and unlocked. It is a preventive confidentiality control, not a detective integrity control. It would not alert the security team to tampering with EHR records.

Configuring syslog forwarding from the EHR servers to a central SIEM

Why it fails: Syslog forwarding collects and centralizes log events, which is useful, but it does not by itself detect unauthorized modification of database records unless the application generates specific integrity events. It is a transport mechanism, not a data-integrity detective control. The scenario calls for detection of record tampering, which syslog alone does not provide.

Deploying an additional host-based firewall on the EHR application servers

Why it fails: A host-based firewall controls network traffic to and from the server but does not inspect or detect changes to database records. It would duplicate the existing preventive network controls rather than add a detective capability at the data layer. The scenario already has network and endpoint controls, so this does not fill the stated gap.

Remove the 'noexec' option from /tmp and /var/tmp so the developer can move scripts there and execute them, keeping /home locked down.

Why it fails: Removing noexec from /tmp and /var/tmp weakens the server's hardening posture by allowing execution from world-writable directories, which is a common malware staging ground. This trades a strong control for a weaker one and does not satisfy the requirement to keep /home secure while enabling legitimate script execution.

Add the 'nosuid' option to /home only, because nosuid prevents all executable files from running and resolves the developer's concern.

Why it fails: The nosuid mount option prevents set-user-ID and set-group-ID bits from taking effect; it does not stop ordinary executable files from running. Therefore adding nosuid to /home would not address a developer's need to run scripts and would not stop script execution, making this option both ineffective and based on a misunderstanding.

Remount /home with the 'noexec' option and require the developer to store and execute scripts from /var/tmp instead.

Why it fails: Remounting /home with noexec would prevent execution of scripts directly from /home, but directing the developer to /var/tmp is poor practice because /var/tmp is world-writable and often allows execution, increasing the attack surface. This does not securely resolve the need and may introduce new risks.

VLAN hopping, where the attacker injects double-tagged frames to reach a different VLAN.

Why it fails: VLAN hopping involves manipulating 802.1Q tags, such as double tagging or switch spoofing, to cross VLAN boundaries. It does not inherently cause a switch port to learn many distinct MAC addresses. While both are Layer 2 attacks, the signature described, a flood of source MACs on one port, points elsewhere. Confusing the two techniques would send the analyst toward the wrong mitigation, such as pruning VLANs rather than port protection.

ARP spoofing, where the attacker sends forged ARP replies to associate their MAC with a victim's IP address.

Why it fails: ARP spoofing poisons hosts' ARP caches so traffic is sent to the attacker's MAC. It typically involves a small number of MAC-to-IP mappings, not a flood of distinct source MAC addresses on a single port. The switch log signature differs: ARP spoofing produces many ARP replies but few unique source MACs, whereas the scenario shows an abnormal volume of learned addresses.

STP root bridge takeover, where the attacker sends superior BPDUs to become the root of the spanning tree.

Why it fails: An STP root bridge takeover involves sending crafted Bridge Protocol Data Units with a lower bridge ID to win the root election and reposition the topology so traffic traverses the attacker. It does not cause a port to learn a large number of MAC addresses. The described CAM table growth is unrelated to spanning-tree topology manipulation and would not be detected through MAC learning logs.

Control Flow Guard (CFG)

Why it fails: CFG validates indirect call targets at runtime, preventing calls to unauthorized addresses. It mitigates control-flow hijacking but does not randomize memory. A use-after-free could still be exploited if the attacker can overwrite a function pointer with an address that is a valid CFG target, such as a legitimate function gadget.

Data Execution Prevention (DEP)

Why it fails: DEP marks memory pages as non-executable, preventing code execution from data regions like the stack or heap. While it can hinder some exploits, it does not randomize memory addresses. A use-after-free exploit can still succeed by reusing a freed object to redirect execution to existing code (e.g., ROP chains) even with DEP enabled.

Structured Exception Handling Overwrite Protection (SEHOP)

Why it fails: SEHOP protects against exploits that overwrite Structured Exception Handler records on the stack. It is not designed to randomize memory and is ineffective against use-after-free vulnerabilities that operate on the heap. SEHOP would not make this exploit significantly more difficult.

Write

Why it fails: The Write permission allows creating and modifying files but does not include Read & execute. Users would be unable to read files they need to work with. The scenario requires read and write access, so Write alone is insufficient. It also lacks Delete, which may be needed for normal file management.

Read & execute

Why it fails: Read & execute allows viewing and running files but not modifying them. SalesTeam members need to write files, so this permission is too restrictive. It would prevent them from saving changes or creating new files. The administrator needs a permission that includes both read and write capabilities.

Full Control

Why it fails: Full Control grants all permissions, including Change permissions and Take ownership. This would allow SalesTeam members to modify ACLs and take ownership, which exceeds the requirement. The administrator explicitly wants to prevent those actions, so Full Control is too permissive and would violate the principle of least privilege.

Deploying the web server on the internal corporate VLAN alongside domain controllers to streamline administrative access and reduce network latency.

Why it fails: Placing public-facing assets directly onto the internal corporate VLAN eliminates critical network boundaries. If an attacker successfully compromises the web server, they immediately gain uninhibited network access to sensitive domain controllers and internal assets without traversing any internal firewalls.

Implementing a flat network topology utilizing unmanaged switches to maximize throughput and simplify routing tables for incoming web traffic.

Why it fails: Flat network topologies completely lack internal segmentation controls. Relying on unmanaged switches prevents administrators from enforcing access control lists or firewall policies between network zones, allowing lateral movement across the entire enterprise infrastructure immediately upon initial exploitation.

Connecting the web server directly to the outer provider edge router via a public bridge to bypass internal switching bottlenecks.

Why it fails: Attaching a web server directly to an external provider edge router exposes the host to unfiltered public traffic and removes essential hardware stateful firewall inspection. This approach invites direct infrastructure attacks and lacks any protective layer against modern network-based volumetric threats.

Eradication

Why it fails: Eradication is the removal of the malicious component and the root cause. While the antivirus quarantined the trojan, the analyst has not confirmed removal of persistence mechanisms or verified the root cause. The scenario describes detection, not the deliberate elimination of the threat, so Eradication is premature here.

Containment

Why it fails: Containment involves limiting the damage and preventing further spread, such as isolating the host from the network. The scenario states the endpoint is still running and no containment actions have been taken. The analyst is only validating the alert, so labeling this Containment skips the critical Identification step that precedes any containment action.

Recovery

Why it fails: Recovery focuses on restoring systems to normal operation and monitoring for recurrence. The endpoint was never taken offline or remediated, so there is nothing to recover. The analyst is still determining whether an incident occurred, which places the activity firmly in Identification rather than Recovery.

Resource Monitor

Why it fails: Resource Monitor shows real-time CPU, memory, disk, and network usage per process, but it does not provide details about loaded modules or memory content. It cannot identify injected code. Therefore, it is not suitable for inspecting process memory for fileless malware.

Task Manager

Why it fails: Task Manager provides basic information about running processes, such as CPU and memory usage, but it does not allow deep inspection of process memory or loaded modules. It cannot reveal injected code or suspicious memory regions. Thus, it is not adequate for detecting fileless malware.

Event Viewer

Why it fails: Event Viewer displays system and application logs, which may contain indicators of compromise, but it does not inspect process memory. Fileless malware often leaves few traces in event logs. While useful for correlating events, it cannot directly detect code injection. Hence, it is not the correct tool for this task.

Security auditing and log monitoring

Why it fails: Auditing and monitoring are detective controls that record access attempts but do not prevent unauthorized access. They may alert after an incident but cannot stop an attacker with physical access from reading the data. Therefore, they do not meet the requirement of ensuring data confidentiality.

Host-based firewall rules

Why it fails: A host-based firewall filters network traffic to and from the server. It has no effect on data at rest or physical access. If an attacker has physical access, they can simply read the disk or boot offline, so firewall rules are irrelevant to this scenario.

NTFS permissions with least privilege

Why it fails: NTFS permissions restrict access based on user or group identity when the OS is running. An attacker with physical access could boot from another OS or remove the disk and read it directly, bypassing NTFS. Thus, it does not protect against physical access as required.

The attacker changed the file permissions to 000 so the agent could no longer read it; enforce file integrity monitoring with auditd watching /var/log/auth.log for permission changes.

Why it fails: Permission changes alone would not explain the missing events if the agent already held an open descriptor, and the stem says the file was removed with shred, which unlinks and overwrites rather than merely chmod-ing it. auditd file watches can detect access and attribute changes, but they do not restore visibility into events that were never forwarded. The root cause is off-host transmission, not local permissions.

The SIEM's correlation engine suppressed duplicate events because the attacker's session generated repeated identical authentication failures; add a threshold rule instead of forwarding changes.

Why it fails: Threshold or deduplication suppression would reduce volume but would not produce a total absence of events for forty minutes while other files continued to arrive. The scenario explicitly states the agent kept forwarding other log files, which rules out a broad ingestion outage. The attacker's action was destructive against a specific file, so throttling logic in the SIEM cannot account for the gap, and adding thresholds would make the blind spot worse.

The attacker exploited a vulnerability in the SIEM agent to stop the service; redeploy the agent with a signed configuration and enable mutual TLS to the SIEM endpoint.

Why it fails: The scenario states the agent remained online and continued forwarding other log files, so a stopped service or compromised agent is inconsistent with the evidence. Mutual TLS and signed configurations are valuable hardening measures, but they do not address the specific loss of authentication events caused by local log destruction. The observable behavior points to file-level tampering, not agent process termination.