Incident Detection And Triage practice questions

lookup table.csv

Why it fails: Lookups are for enrichment, not joining live streams.

sort by user_id

Why it fails: Sorting does not correlate events.

eval user_id = field1

Why it fails: Eval is for field modification, not correlation.

To identify the physical location of the server.

Why it fails: Location is secondary to the reliability of the source.

To see how much storage the source uses.

Why it fails: Storage usage is not relevant to triage.

To check the manufacturer's warranty.

Why it fails: Warranty is not related to security operations.

Change the alert severity level in the 'Incident Review' dashboard settings.

Why it fails: Severity changes do not affect the underlying data fields of the event.

Edit the correlation search definition to pipe the results into the 'inputlookup' command for user data.

Why it fails: inputlookup reads data, it does not enrich the event stream dynamically.

Modify the 'Notable Event Aggregation Policy' to force a refresh of the user metadata.

Why it fails: Aggregation policies group events; they do not perform data enrichment.

Use a simple threshold rule set to trigger only on the 5th failure without defining distinct source IP criteria.

Why it fails: A plain threshold counts five failures regardless of origin, so a single source IP triggers it and the three-distinct-source-IP condition is never evaluated. It is tempting because threshold rules are the standard QRadar building block for volumetric detection, and would suffice without the distinct-IP requirement.

Create a rule using the 'when the event matches any of these building blocks' condition combined with an 'and when at least 5 events are seen with the same username in 1 minute' filter.

Why it fails: This does not account for the requirement of three distinct source IP addresses.

Enable the 'Flow-based Anomaly' detection setting in the system configuration to automatically detect brute-force patterns.

Why it fails: Flow-based detection is for network traffic patterns, not authentication log events.

Run a full antivirus scan on the server to detect other malware files.

Why it fails: A full antivirus scan may detect other known malware, but it can miss modified or zero-day threats. The specific file in question may be a legitimate tool with added malicious code that antivirus might not catch. Antivirus relies on signatures and heuristics, which can be evaded. Memory analysis is more reliable for active infections because it examines runtime behavior.

Check the file's digital signature to verify if it is valid and trusted.

Why it fails: Checking the digital signature can reveal if the file was tampered with, but if the malware author re-signed it or removed the signature, it may not be conclusive. A valid signature might still be present if the attacker stole a certificate. Additionally, the absence of a signature does not confirm maliciousness. Memory analysis is a more direct method to confirm infection.

Submit the file to a multi-engine antivirus scanner like VirusTotal to see if other engines detect it as malicious.

Why it fails: Submitting the file to VirusTotal can provide additional detection, but it is not definitive. Some engines may flag it as a false positive, and the malware author may have modified the file to evade detection. VirusTotal results can be inconclusive. The analyst needs to examine the file's behavior or code to confirm malicious modifications, not rely solely on external scanners.

To compress log size for storage efficiency.

Why it fails: Normalisation maps fields to a shared schema for cross-source correlation; storage reduction comes from compression and retention policies. It tempts because normalised events can be stored more compactly, and shrinking index size would be the aim when configuring storage tiers or archiving.

To hide sensitive information.

Why it fails: Normalisation standardises field names and formats for correlation; masking sensitive data is data obfuscation or tokenisation. It tempts because normalised pipelines often apply redaction, and hiding personally identifiable information would be the goal when meeting privacy regulations during ingestion.

To increase the ingestion speed.

Why it fails: Normalisation parses heterogeneous sources into a common schema so fields correlate across vendors; ingestion throughput is governed by parsers and pipeline capacity instead. It tempts because parsing does consume compute, and reducing that overhead would be the goal when tuning collector performance.

Unions only support structured data.

Why it fails: Unions handle structured and semi-structured data alike, so the claim is false. The real distinction is that a union appends rows into one result set, whereas a join correlates columns from both tables on matching keys — which is what lateral-movement detection across SecurityEvent and SigninLogs requires.

Joins consume less memory than unions.

Why it fails: Joins match rows across tables on a key, producing correlated pairs; unions stack rows with identical schemas. Memory consumption is not the axis of difference, and a join can actually require more working memory due to the hash build side. Joins are chosen for correlation, not for resource economy.

Unions cannot be used in detection rules.

Why it fails: Union does work in detection rules; it appends rows from both tables, which cannot correlate a sign-in with its matching security event. Join is chosen precisely when fields must be matched across tables to link related activity.

Alert frequency.

Why it fails: Alert frequency measures volume, not consequence; a noisy low-impact rule outranks a single critical breach. Frequency is tempting because repeated alerts feel urgent, yet it would only be the right metric when tuning correlation thresholds or reducing false-positive noise in detection engineering.

Log source vendor.

Why it fails: Log source vendor says nothing about business impact; triage prioritisation uses asset criticality and data sensitivity to rank incidents. Vendor is tempting because it hints at telemetry reliability, yet it would only matter when tuning parser coverage or assessing detection gaps, not when ranking impact.

Number of alerts per user.

Why it fails: Alerts per user indicates activity concentration, not business consequence; triage prioritisation weighs asset criticality and data classification. Per-user counts are tempting because anomalies suggest compromise, yet they would only be relevant when profiling behaviour or detecting credential misuse, not when ranking impact.

The parser is disabled.

Why it fails: A disabled parser stops events being normalised into fields, so the correlation rule's conditions never match the raw data. Parser configuration is the correct focus when events arrive but their fields are missing or malformed, not when filters are already verified.

The user interface is loading slowly.

Why it fails: Slow interface rendering affects only the console display and does not prevent the correlation engine from evaluating events server-side. Interface performance is the right concern when dashboards lag or time out, not when a rule fails to fire.

The license has expired.

Why it fails: An expired licence halts ingestion or rule evaluation entirely, producing silence across all rules rather than one rule failing while others run. Licence renewal is the correct action when the manager refuses to start or stops processing altogether.

Escalate to the ISP immediately.

Why it fails: This is ineffective during initial triage.

Disable the rule for all cloud traffic.

Why it fails: Disabling the rule for all cloud traffic blinds detection across legitimate and hostile sources, creating a permanent coverage gap. Rule tuning should instead add context such as known provider ranges, threat intelligence or authentication thresholds, preserving visibility while reducing noise from benign cloud-hosted services.

Ignore the alert as cloud IPs are always false positives.

Why it fails: Cloud provider IP ranges host legitimate customer workloads and attacker-controlled infrastructure alike, so origin alone cannot clear an alert. Dismissing all such alerts as false positives suppresses genuine brute-force activity; classification requires correlating authentication failures, geolocation and account context before disposition.

Isolate the host immediately.

Why it fails: Isolation is containment, which follows initial triage: validating the alert, scoping affected hosts and preserving volatile evidence. Cutting the host first can tip off an attacker and destroy memory-resident artefacts. Immediate isolation suits confirmed active exfiltration or ransomware spreading across the estate.

Reimage the affected workstation.

Why it fails: This is a remediation step, not triage.

Contact the user's manager.

Why it fails: Manager notification is an escalation and communication step, not triage; it neither validates the alert nor preserves evidence, and delays containment decisions. Triage first confirms the connection, scopes affected systems and captures volatile data. Manager contact suits post-containment briefing or insider-threat cases needing HR involvement.

Increase the storage allocation for the log source.

Why it fails: Storage allocation governs event retention and licence consumption, not QID assignment; parsed events without a QID are a normalisation problem, not a capacity one. Increasing allocation suits environments exceeding EPS or retention limits, while unmapped events require a custom DSM or log source extension.

Upgrade the firmware on the log source.

Why it fails: Firmware on the appliance governs how it emits logs, not how QRadar interprets them; events already arrive and parse, so the source is transmitting correctly. Firmware upgrades address changed or malformed log formats at the sender, whereas unmapped events need a DSM or log source extension defining QID mappings.

Restart the Event Processor service.

Why it fails: Restarting the Event Processor interrupts ingestion and rebuilds nothing about QID mapping; events already parse, so the parser is fine. A restart is the remedy for stalled or crashed processing pipelines, not for unmapped events, which require a custom DSM or log source extension mapping the fields to a QID.

Delete the correlation rule and recreate it.

Why it fails: Deleting and recreating the rule reproduces the identical search and threshold, so the same false positives recur once it is re-enabled. Recreating suits migrating rules between apps or rebuilding corrupted saved searches, not suppressing noisy detections that need threshold or filter adjustment.

Enable packet capture on all domain controllers.

Why it fails: Packet capture records traffic but does not alter correlation rule logic, so false positives persist. It tempts as a forensic step to inspect authentication traffic, yet tuning requires adjusting the rule's threshold, time window or field filters, or adding a risk-based exception.

Change the rule severity to 'Informational'.

Why it fails: Lowering severity to Informational only changes how alerts are triaged; the rule still fires on every threshold breach, so false-positive volume is unchanged. Severity tuning suits environments where detection is valid but non-urgent, not where the underlying threshold logic itself generates noise.

Writing the correlation query.

Why it fails: Writing the correlation query comes after the use case's purpose, data sources and logic are defined; querying first produces alerts with no agreed detection requirement. Query authoring is the correct step once the use case has been designed and its required log sources identified.

Testing the alert in production.

Why it fails: Testing in production occurs after the use case is built and validated in a non-production environment; testing first risks unvalidated alerts firing on live data. Production testing is correct as the final verification stage before full operational rollout of a completed use case.

Documenting the playbook.

Why it fails: Documenting the playbook happens near the end, after detection logic is built and validated, since it records the response steps for a working alert. Playbook documentation is correct once the use case is operational and analysts need consistent triage and escalation guidance.

Analyze logs for malware.

Why it fails: Collectors normalise and forward raw events; malware analysis is performed by the correlation engine, analytics rules or sandboxing components downstream. Analysing logs for malware would be the correct function when the requirement is behavioural detection rather than ingestion of telemetry.

Encrypt stored logs.

Why it fails: A collector's role is to receive and forward event data to the SIEM for correlation and storage; encryption of stored logs is handled by the storage or retention layer, not the collector. Encryption at rest would be the correct control when regulatory requirements demand confidentiality of archived log data.

Block malicious traffic.

Why it fails: A collector only gathers and forwards log or event data to the SIEM for normalisation and analysis; blocking traffic is enforcement performed by firewalls or IPS. It is tempting because SIEM platforms can initiate blocking via integrations, and that would be correct if the question asked about automated response rather than collection.

Log rotation.

Why it fails: Log rotation archives or deletes old files to control disk usage, which neither correlates nor groups events. It is tempting because it manages the volume of retained log data, and rotation would be the right answer if the question concerned storage lifecycle or preventing files from filling a filesystem.

Dashboard visualization.

Why it fails: Dashboard visualisation renders queries and metrics graphically for analysts, without joining events into one incident. It is tempting because grouped alerts often appear on dashboards, and visualisation would be correct if the question asked how to present correlated findings to stakeholders.

Data ingestion.

Why it fails: Data ingestion parses and normalises raw source feeds into the SIEM, producing individual events rather than linking them. It is tempting because ingestion precedes all correlation, and it would be correct if the question asked how logs from disparate sources enter the platform for indexing.

Only alert on weekend traffic.

Why it fails: Weekend-only alerting narrows the detection window to two days, missing exfiltration during the working week, and does not refine the 500MB threshold itself. It is tempting because off-hours activity often indicates malicious behaviour, so baselining by time would suit environments where legitimate bulk transfers occur only in business hours.

Disable alerts for file servers.

Why it fails: Disabling alerts on file servers removes visibility entirely, so genuine exfiltration from those hosts would go undetected. It is tempting when file servers generate noisy volume-based false positives, but the correct fix is tuning the threshold or adding context, not suppressing the data source.

Lower the threshold to 50MB.

Why it fails: Lowering the threshold to 50MB increases false positives from routine backups and software updates rather than improving accuracy. It is tempting because a smaller volume catches exfiltration sooner, and it would be the right choice where normal transfer volumes are genuinely low and tightly baselined.

Hardware reduction in the datacenter.

Why it fails: SIEM centralises log collection, correlation and alerting; it does not remove the need for underlying hardware, since collectors, storage and processing still require infrastructure. Hardware consolidation is the goal of virtualisation or hyperconverged platforms, not SIEM deployment.

Elimination of all false positives.

Why it fails: Correlation rules and tuning reduce false positives but cannot eliminate them, since detection logic always trades precision against recall. False-positive suppression is the aim of tuning and threat-intelligence enrichment, not a property of centralised logging itself.

Automatic remediation of all threats.

Why it fails: Automatic remediation exceeds SIEM scope: a SIEM aggregates and correlates log data, generating alerts for analysts, but does not itself execute response actions across endpoints. It tempts because SOAR platforms do automate remediation playbooks, which would be the right answer had the question asked about orchestrated response rather than centralised monitoring.

Reimage the database server.

Why it fails: Reimaging the database server destroys forensic evidence and causes outage despite no indication of compromise, since the payload strings are harmless. It is tempting as aggressive remediation after confirmed host compromise, but this alert requires triage, not eradication.

Close the alert as 'Benign'.

Why it fails: Closing as Benign skips investigating why the detection fired, so a genuine evasion attempt using obfuscated harmless-looking strings could be missed. It is tempting to reduce alert queue volume, but benign classification should follow analysis confirming the payload cannot execute, not precede it.

Block the source IP on the edge firewall.

Why it fails: Blocking the source IP treats a harmless payload as confirmed malicious traffic, potentially disrupting legitimate users without evidence of exploitation. It is tempting as containment when an attack is verified, but here the strings are benign, so the alert needs investigation and tuning rather than firewall action.

Disable the rule entirely.

Why it fails: Disabling the rule removes detection of genuine scanner abuse or compromise masquerading as scanning, leaving that activity entirely unmonitored. Disabling suits rules that are wholly obsolete or duplicated. Here the rule detects real behaviour; it needs the scanner's source addresses excluded, not switched off.

Upgrade the vulnerability scanner.

Why it fails: Upgrading the scanner changes nothing about how the SIEM correlates its traffic; the same events keep matching the rule. Scanner upgrades address detection coverage or performance gaps. The problem is rule logic treating a trusted internal source as hostile, which an allowlist exclusion resolves.

Increase the rule threshold.

Why it fails: Raising the threshold still fires on scanners once they exceed it, and suppresses genuine low-volume attacks that fall beneath the new limit. Threshold tuning suits noisy rules where volume itself distinguishes abuse. Here the scanner is a known benign source, so an allowlist exclusion is required instead.