Log Management and SIEM practice questions

Multiple failed authentication attempts originating from a single IP address targeting the same administrative account.

Why it fails: Targeting a single administrative account from one IP address typically indicates a classic brute-force attack or password guessing rather than a distributed credential stuffing campaign. Credential stuffing specifically relies on testing numerous distinct usernames against multiple endpoints to evade simple account lockout thresholds.

A successful authentication event immediately followed by an administrative permission escalation within the same session.

Why it fails: Rapid privilege escalation following a valid login characterizes post-exploitation internal movement or compromised administrative credentials rather than initial credential stuffing attempts. This pattern fails to identify the bulk automated enumeration phase characteristic of credential stuffing operations.

Frequent password reset requests submitted by external IP addresses during non-business operating hours.

Why it fails: Password reset requests reflect user self-service account recovery actions or social engineering attempts rather than direct automated credential validation attacks. Monitoring reset requests alone misses the primary mechanism of credential stuffing which exploits active authentication interfaces.

An interactive local login where the user authenticated directly at the physical console keyboard and mouse.

Why it fails: Interactive local logins correspond to Windows Logon Type 2, which occurs when a user physically logs into the workstation console. Event ID 4624 with Logon Type 3 specifically denotes network access rather than local physical interaction.

A remote desktop session connection authenticated via Network Level Authentication and Remote Desktop Protocol.

Why it fails: Remote desktop connections typically generate Windows Logon Type 10 for interactive remote sessions rather than standard network share access. Misidentifying logon types can cause analysts to misinterpret lateral movement vectors during forensic investigations.

A background service startup execution authenticated under the local system service account context.

Why it fails: Service startup and background execution events typically involve Windows Logon Type 5 or specialized service account tokens rather than network authentication. The presence of a distinct source IP address directly refutes internal service startup activity.

A brute-force password guessing attack was successfully executed against the root user account.

Why it fails: The log explicitly states that public key authentication with an RSA SHA256 key was accepted, which refutes password-based brute-force activity. Brute-force attacks typically generate repeated password failures prior to any successful authentication entry.

An unauthorized privilege escalation attempt failed because the user jsmith lacked sudo permissions.

Why it fails: The second log entry shows a successful sudo command execution for user jsmith, not a failure. The command explicitly spawned a bash shell under the root user context, confirming successful privilege elevation.

The SSH daemon experienced a critical configuration failure and dropped incoming connection requests.

Why it fails: The SSH daemon successfully accepted the incoming public key connection and established a valid session for the root user. There are no error indicators or daemon failure messages present in the provided log excerpt.

Regularly clearing the event logs to free up storage space for new logs.

Why it fails: Clearing logs destroys historical data and creates gaps in the audit trail, which is a major security risk. Forensic evidence must be preserved according to organizational retention policies to ensure that historical analysis remains possible during an incident response investigation when tracing attacker activity across a network.

Storing all log files in a shared network folder with everyone having read access.

Why it fails: Shared folders without granular access control allow unauthorized users to read or modify sensitive log files. Security best practices dictate that log repositories must be locked down, following the principle of least privilege, to prevent malicious actors from altering evidence or discovering sensitive information contained in logs.

Using a simple text file format for all logs to ensure maximum compatibility.

Why it fails: Plain text logs are easily modified by any user with basic file system access. Relying on plain text without additional security controls or checksums provides zero assurance of integrity, making it trivial for an attacker to remove their tracks or inject fake log entries to mislead security analysts.

Increased local disk space availability on individual workstations.

Why it fails: While offloading logs might free up local disk space, it is a secondary benefit rather than a primary goal of CLM. Centralized management is fundamentally about security visibility, operational efficiency, and legal audit requirements, not purely about optimizing local host storage capacity for general system performance or maintenance.

Elimination of the need for an enterprise firewall.

Why it fails: CLM is a diagnostic and forensic tool, not a preventative control. It does not provide network filtering or packet inspection capabilities. Security architectures must include perimeter defenses like firewalls alongside logging systems; they are complementary rather than interchangeable parts of a defense-in-depth strategy for protecting corporate network resources.

Automatic removal of all malicious actors from the network.

Why it fails: Log management systems are passive observers. They identify and alert on threats but do not possess native active defense mechanisms to automatically remove or block attackers. Remediation requires an orchestration tool (SOAR) or manual intervention by security analysts, as logs only document events rather than actively enforcing security policy.

Windows Security Event ID 5156 joined with Zeek conn.log on the process ID (PID).

Why it fails: Windows Security Event ID 5156 (Filtering Platform Connection) logs allowed connections but does not include a PID that directly maps to Zeek's conn.log. Zeek does not record PID. While 5156 does have ProcessID, there is no corresponding field in Zeek to join on, and PID reuse across systems makes this correlation unreliable. This approach would not yield accurate process-to-flow mapping.

Zeek conn.log (uid) joined with Sysmon Event ID 3 (ProcessGuid) on matching timestamps.

Why it fails: Zeek conn.log contains network flow metadata such as uid, but no process identifiers. Sysmon Event ID 3 (NetworkConnect) includes ProcessGuid and Image, but there is no direct field to join with Zeek's uid. Correlating solely on timestamps is imprecise due to clock skew and high-volume traffic, leading to false matches and unreliable attribution of the outbound flow to a specific process.

Zeek http.log (host, uri) joined with Sysmon Event ID 22 (QueryName) on matching domain names.

Why it fails: Zeek http.log records HTTP requests with host and URI, while Sysmon Event ID 22 logs DNS queries. Joining on domain names could link HTTP traffic to DNS lookups but does not identify the process that initiated the outbound flow. This method is limited to HTTP and DNS and cannot attribute arbitrary network flows to a specific process, failing the requirement.

Windows Security Event ID 4648 (A logon was attempted using explicit credentials).

Why it fails: Event ID 4648 is logged when a process attempts an explicit logon using credentials, such as when using RunAs or connecting to a network share with different credentials. While it can indicate lateral movement, it is not specific to RDP and does not include the LogonType 10. It would capture other types of credential use, leading to false positives if used for RDP detection. It is not a primary source for RDP logon correlation.

Windows Security Event ID 4625 with LogonType 10.

Why it fails: Event ID 4625 with LogonType 10 indicates failed RDP logon attempts. While failed attempts can indicate brute force, the scenario specifically seeks successful authentications to multiple hosts. Including failed logons would generate noise and false positives, as many failed attempts might occur before a successful one. The correlation should focus on successful logons to detect actual lateral movement, not just attempts.

Windows Security Event ID 4776 (The domain controller attempted to validate the credentials for an account).

Why it fails: Event ID 4776 is generated on domain controllers when NTLM credentials are validated. It does not specify the logon type (e.g., RDP) and does not indicate the destination host of the logon. While it can be used to track authentication attempts, it lacks the context needed to correlate RDP lateral movement across multiple hosts. It would require additional correlation with other events, making it less direct than 4624.

Disable all failed login logging on domain controllers to save SIEM storage.

Why it fails: Disabling logging entirely blinds the security team to brute-force attacks and unauthorized access attempts. This approach violates the principle of least privilege and eliminates visibility into credential-based threats, rendering the SIEM ineffective for detecting account compromise or lateral movement activities within the enterprise network infrastructure.

Increase the severity level of all login failure logs to 'Critical'.

Why it fails: Changing the severity level does not reduce the volume of incoming log data or the frequency of alerts triggered. It simply reclassifies the noise, which complicates incident prioritization and potentially causes analysts to miss actual high-priority security incidents buried within a high volume of incorrectly prioritized alerts.

Archive all failed login logs to cold storage immediately upon ingestion.

Why it fails: Moving logs to cold storage prevents the SIEM correlation engine from processing them in real-time. This action makes it impossible for the SIEM to identify patterns of attack or trigger automated responses, defeating the primary purpose of having a centralized log management and security information system.

Hardware failure; replace the server network interface card immediately.

Why it fails: Failed login attempts are authentication-related security events, not hardware errors. Replacing a network interface card will not stop authentication attempts from a remote host. Diagnosing this as a hardware fault demonstrates a failure to distinguish between systemic environmental logs and malicious activity patterns observed in authentication logs.

Network congestion; increase the logging frequency of the server.

Why it fails: Log data related to login failures provides evidence of authentication issues, not network traffic congestion problems. Increasing logging frequency would only generate more logs while failing to address the underlying security threat, which is a malicious actor attempting to brute-force credentials against a sensitive enterprise server host.

User error; reset the user's password to clear the event logs.

Why it fails: Resetting a password does not stop an external attacker from attempting to brute-force the account. Furthermore, clearing event logs is a counterproductive action that destroys evidence needed for forensic analysis. Analysts should prioritize identifying the source and blocking access rather than attempting to remediate through password resets.

Local printer spooler temporary files

Why it fails: Printer spooler files contain transient print job data that is rarely useful for security monitoring. Ingesting these files would consume massive amounts of SIEM storage without providing meaningful security insights, diverting resources away from high-value logs like authentication and network traffic logs that actually detect active security incidents.

Office document metadata templates

Why it fails: Document metadata templates are part of the office suite configuration and do not provide actionable security intelligence regarding system or network activity. Ingesting this non-security data clutters the SIEM database, increases costs, and impedes the ability of analysts to query and find relevant security-related events during an investigation.

Set the rule to alert only when event ID 4625 occurs outside of business hours.

Why it fails: Time-of-day filtering is a weak heuristic because attackers can operate during business hours, and legitimate remote workers may fail logons at night. This approach would both miss many brute-force attacks and still generate false positives from after-hours user errors, failing to address the root cause of noise.

Add a filter to exclude all failed logon events from privileged accounts.

Why it fails: Excluding privileged accounts is dangerous because attackers often target administrative accounts first. This would suppress detection of high-risk brute-force or password-spraying attacks against domain admins and service accounts, creating a major blind spot rather than reducing false positives intelligently.

Configure the rule to trigger only when event ID 4625 is followed by event ID 4624 (successful logon) from the same user within 1 minute.

Why it fails: This pattern might indicate a successful guess after failures, but it is not specific to brute force and can generate false positives from legitimate users who mistype once then succeed. It also misses sustained brute-force attempts that never succeed, which are still important to detect and block.

Alert when any host initiates a connection to a country that is not on an approved list.

Why it fails: Country-based blocking is a blunt instrument. Attackers can use proxies or cloud services in approved countries, and legitimate business may involve connections to many countries. This rule would generate many false positives and miss exfiltration to allowed geographies, failing to detect the actual data transfer behavior.

Alert when any internal host sends more than 1 GB of data to an external IP address within an hour.

Why it fails: A static volume threshold like 1 GB per hour is easily evaded by exfiltration that stays below the threshold or by legitimate large transfers such as backups or cloud syncs. It also generates false positives for authorized high-volume traffic. Effective detection requires baselining normal behavior and considering destination reputation and protocol.

Monitor for DNS queries to known command-and-control domains and alert on any match.

Why it fails: DNS monitoring is valuable for detecting command-and-control, but it does not directly detect data exfiltration over the network. Exfiltration can occur over HTTP/HTTPS, FTP, or other protocols without distinctive DNS queries. This approach addresses a different stage of the attack lifecycle and would not reliably identify large outbound data transfers.

Add a threshold condition that triggers only when more than 10 failed logins occur from the same source IP within 5 minutes.

Why it fails: Thresholding by a single source IP within a short window is a common tuning step, but it does not address distributed brute-force attacks where each source IP generates only a few failures. It also fails to reduce noise from a single user who mistypes a password once, because that event still counts as one failure and would not meet the threshold, but the search would still evaluate each event. The scenario specifically requires catching distributed attacks, so this approach is insufficient.

Increase the search time window to 24 hours and lower the alert threshold to 5 failed logins per user.

Why it fails: Extending the time window and lowering the threshold would likely increase the number of alerts, not reduce them. A longer window captures more legitimate failures, and a lower threshold makes it easier to trigger on benign activity such as a user who mistypes a password a few times. This tuning direction is opposite to what the analyst needs, and it does not specifically target distributed brute-force patterns.

Filter out all failed password events for service accounts and only alert on failed logins for interactive user accounts.

Why it fails: Filtering out service account failures ignores a critical attack vector, because attackers often target service accounts with brute-force attempts. This change would reduce noise only if the noise originated from service accounts, which the scenario does not state. More importantly, it does not help detect distributed brute-force attacks against interactive accounts, so it fails to meet the requirement of catching distributed attacks while reducing false positives.

Reduce the log retention period to 30 days and rely on the original log sources to retain their own logs for one year.

Why it fails: Relying on source systems to retain logs for a year is risky because many sources have limited local storage and may overwrite logs quickly. It also complicates compliance audits, as logs are scattered and may not be tamper-evident. This approach does not ensure centralized retention and could lead to gaps if a source is compromised or decommissioned. It fails to meet the requirement cost-effectively and reliably.

Increase the SIEM's primary storage capacity by adding more high-performance disks to accommodate one year of logs.

Why it fails: Adding high-performance primary storage is expensive and unnecessary for older logs that are rarely accessed. It does not leverage cost-effective tiers and may not scale well as log volume grows. While it would meet retention, it is not the most cost-effective strategy. The scenario explicitly mentions that primary storage is expensive and limited, so expanding it contradicts the goal of cost-effectiveness.

Disable logging for low-priority sources and keep only high-priority logs for one year on primary storage.

Why it fails: Disabling logging for low-priority sources reduces visibility and may violate compliance requirements that mandate logging from all critical systems. It does not address the retention of logs from high-priority sources, which may still exceed primary storage capacity. This approach sacrifices security monitoring for cost savings and does not provide a scalable retention solution. It fails to meet the requirement without compromising security.

Install a SIEM agent on the domain controller to read the event logs directly and forward them in a normalized format.

Why it fails: Installing a SIEM agent could bypass WEF and send logs in a format the SIEM understands, but it introduces additional management overhead and may not be necessary. The scenario specifies that WEF is already active and events are arriving; the problem is parsing, not collection. Adding an agent does not address the root cause and could create duplicate events if WEF remains enabled, complicating the SIEM data ingestion.

Configure the SIEM to use the Windows Event Log collector with the correct channel names and enable XML parsing.

Why it fails: While using a Windows Event Log collector can help, the issue is that the logs are arriving as raw XML. Simply enabling XML parsing in the collector may not map the fields to the SIEM's schema. The collector must be configured with the appropriate event channel and a parsing ruleset that extracts fields from the XML structure. Without the correct parser, the SIEM will still store raw XML, so this action alone does not resolve the normalization problem.

Modify the WEF subscription to forward events in JSON format instead of XML.

Why it fails: Windows Event Forwarding natively forwards events in XML format; there is no built-in option to change the output to JSON. While some third-party tools can convert XML to JSON, WEF itself does not support this. Attempting to modify the subscription to output JSON is not feasible and would not resolve the parsing issue. The correct approach is to adapt the SIEM's parser to the XML format.

DNS server query logs.

Why it fails: DNS query logs show domain name resolution requests, which can indicate command-and-control or data exfiltration via DNS tunneling, but they do not provide byte counts for outbound connections. While DNS tunneling can exfiltrate data, the volume is usually small and not representative of typical data transfers. For measuring the volume of data over connections, DNS logs are insufficient. They are better for detecting anomalous domains or query patterns.

Windows Security event logs from the source host.

Why it fails: Windows Security event logs may record logon events, process creation, and object access, but they do not typically include byte counts for outbound network connections. They could show that a process initiated a connection, but not how much data was transferred. Without network-level volume data, the analyst cannot estimate exfiltration size. This source is useful for host-based activity but not for measuring data volume.

Antivirus application logs from the endpoint.

Why it fails: Antivirus logs record malware detections, scan results, and sometimes blocked connections, but they do not measure the volume of data transferred. They might indicate that an exfiltration attempt was blocked, but not how much data left the network. For estimating exfiltration volume, antivirus logs are not a direct or reliable source. They are more useful for identifying known threats on the endpoint.

VPN concentrator logs with the UserName field and the AssignedIP field.

Why it fails: VPN logs show remote access connections but do not record file-level access. They can indicate which user was connected at 2:00 AM, but not which files they accessed. The analyst needs to correlate VPN logs with file access logs, but the question asks for the log source that directly identifies the user account that initiated the file access. VPN logs alone cannot provide that specific information.

Linux auditd logs with the key field set to "file_access" and the uid field.

Why it fails: Linux auditd can log file accesses if configured with audit rules, but the scenario specifies a sensitive file server, which is likely Windows-based given the other log sources. Even if it were Linux, the uid field provides a numeric user ID, not a username, requiring additional mapping. Without knowing the file server's OS, this is not the best choice. The Windows Security log is more directly applicable if the file server is Windows.

Windows Security Event ID 4624 (An account was successfully logged on) with the TargetUserName field.

Why it fails: Event ID 4624 logs successful logons, not file accesses. While it can show that a user logged on to the file server, it does not indicate which files were accessed. The analyst needs to identify the user who accessed a specific file, so a logon event is insufficient. The correct event is 4663, which records object access attempts and includes the user account.

Configuring the SIEM to drop logs that do not match the expected format to reduce noise.

Why it fails: Dropping logs that do not match the expected format can lead to loss of critical security events. While it may reduce noise, it also risks discarding logs that could contain indicators of compromise or that require investigation. A better approach is to parse and normalize logs, and if parsing fails, to route them for review. Dropping logs is not an essential task for normalization and enrichment; it can harm visibility.

Storing all raw logs indefinitely in their original format without normalization.

Why it fails: Storing raw logs indefinitely is costly and does not support correlation. Without normalization, the SIEM cannot easily correlate events across sources because field names and formats vary. While retaining raw logs for a period can be useful for forensic deep dives, it is not an essential task for normalization and enrichment. The goal is to make data usable for correlation, which requires normalization and enrichment, not just raw storage.

Increasing the SIEM's indexing speed by disabling timestamp recognition on all logs.

Why it fails: Disabling timestamp recognition would break event ordering and correlation, as the SIEM relies on timestamps to sequence events and correlate across sources. It might speed up indexing slightly, but at the cost of accuracy and functionality. Timestamp recognition is fundamental for log management and SIEM operations. This task is not essential for normalization and enrichment; it would undermine them.

Firewall logs showing outbound connections from the VPN-assigned IP address.

Why it fails: Firewall logs can show what the user did after connecting, such as accessing internal resources or exfiltrating data. This might reveal malicious activity, but it does not directly confirm whether the login itself was legitimate travel. The analyst could infer intent from subsequent actions, but that requires deeper investigation. For a quick determination of legitimacy, HR travel records are more direct and authoritative.

VPN concentrator logs showing the assigned IP address and session duration for the successful login.

Why it fails: VPN concentrator logs provide session details but do not directly indicate user legitimacy. They can confirm the session but not whether the user is traveling or an attacker. While useful for correlation, they lack the behavioral context needed to distinguish a compromised account from legitimate travel. The analyst needs information about the user's normal behavior and location patterns, which this source does not provide.

Endpoint detection and response (EDR) logs from the user's laptop.

Why it fails: EDR logs can show process activity, malware detections, and network connections on the endpoint. However, if the user is traveling, the laptop may not be on the corporate network, and EDR logs might not be available or up-to-date. They could indicate compromise if malware is present, but absence of malware does not prove legitimate travel. EDR is useful but less direct than HR travel records for this specific determination.

Cross-site scripting (XSS)

Why it fails: XSS attacks typically involve injecting malicious scripts into web pages viewed by other users. While XSS payloads may include encoded characters, the presence of %27 (single quote), %20 (space), and %3D (equals) in a URL with successful responses is more indicative of SQL injection attempts. XSS would more commonly show script tags or JavaScript in the URL, not just these specific encoded characters.

Directory traversal

Why it fails: Directory traversal attacks use sequences like ../ or encoded variants (%2e%2e%2f) to access files outside the web root. The characters %27, %20, and %3D are not typical for directory traversal. They are more commonly associated with SQL injection. Directory traversal would show attempts to navigate file paths, not SQL syntax elements.

Command injection

Why it fails: Command injection involves injecting operating system commands via input fields. While encoded characters can appear, typical command injection payloads include semicolons (%3B), pipes (%7C), or backticks. The specific combination of %27, %20, and %3D is more characteristic of SQL injection. Command injection would more likely show attempts to execute commands like ls or cat, not just these encoded characters.