Cyber Security Quiz: Siem

10 questions · exam conditions

0:00

SiemQuestion 1 of 10

A SIEM rule looks for an endpoint process launch followed within five minutes by a successful remote login from the same device. Endpoint events consistently appear to occur three minutes after the corresponding authentication events, although packet captures confirm that the process launches actually occurred first. Both sources already report timestamps in UTC.

Which action would most improve the accuracy of this sequence correlation without unnecessarily widening the detection window?

Use ingestion time for both sources because arrival order is more reliable than source-generated event time

Synchronize the source clocks and permit a bounded amount of out-of-order event processing

Reverse the sequence in the rule because authentication events currently have earlier source timestamps

Extend the correlation window substantially so either apparent event order will satisfy the rule

← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Siem

Practice Siem in Cyber Security with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Siem, giving you a quick way to practice the rules, question types, and explanations that matter most for Cyber Security.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

Which action would most improve the accuracy of this sequence correlation without unnecessarily widening the detection window?

Use ingestion time for both sources because arrival order is more reliable than source-generated event time
Synchronize the source clocks and permit a bounded amount of out-of-order event processing (correct answer)
Reverse the sequence in the rule because authentication events currently have earlier source timestamps
Extend the correlation window substantially so either apparent event order will satisfy the rule

Explanation: When SIEM correlation rules depend on event sequence, you need to think carefully about two distinct problems: clock accuracy and event arrival order. Here, packet captures prove the process launches happened first, yet the SIEM sees authentication events arriving earlier. That gap — a consistent three-minute skew — points to a clock synchronization problem between the two sources, not a flaw in the rule's logic. The right fix, answer B, addresses both root causes simultaneously. Synchronizing clocks via NTP eliminates the timestamp skew so events reflect their true order. Adding bounded out-of-order processing (a small tolerance window, e.g., a few minutes) handles any residual network or ingestion delays without permanently distorting your detection logic. Together, these restore accurate sequencing without sacrificing rule precision. A is tempting but wrong: ingestion time reflects when events arrived at the SIEM, which depends on network latency, log forwarder queues, and pipeline delays — all of which vary unpredictably. Trusting arrival order would introduce new, harder-to-control inaccuracies rather than fix the existing ones. C sounds clever since authentication timestamps are currently earlier, but you'd be encoding a known clock error directly into your rule. If clocks are later fixed, your rule would immediately break, and you'd be detecting a false sequence in the meantime. D widens the correlation window "substantially," which increases detection coverage but at the cost of catching more false positives and weakening the precision of the five-minute behavioral indicator the rule was designed around. Remember: when you see timestamp anomalies in SIEM questions, always distinguish between clock skew (fix at the source) and arrival-order jitter (handle with bounded buffering) — B addresses both correctly.

Question 2

After a network appliance update, a SIEM dashboard shows no normalized deny events from that appliance. Collector health is normal, packet loss is not reported, and searches of the raw event archive confirm that deny messages continue to arrive. Correlation rules that depend on the normalized action field also stop producing alerts.

Which explanation is most consistent with all of the evidence?

The appliance stopped generating deny events even though its raw messages continued to arrive
The collector lost connectivity after receiving each message but before storing the raw event
The appliance's revised message format no longer maps correctly through the existing parser (correct answer)
The correlation rules suppressed deny events before the collector could receive and archive them

Explanation: When troubleshooting a SIEM pipeline, you need to mentally trace the data flow: raw events are collected, parsed/normalized into structured fields, then fed into correlation rules. If something breaks in the middle of that chain, you'll see symptoms both upstream and downstream of the break point — which is exactly the diagnostic logic this question tests. Here, the evidence forms a very specific pattern: raw deny messages are arriving and archiving successfully, but the normalized action field is missing or incorrect, causing correlation rules to fail silently. This points directly to the parser — the component that transforms raw text into structured, normalized fields. After the appliance firmware update, its log format likely changed (different field ordering, delimiter, or keyword), so the existing parser no longer recognizes and maps the deny action correctly. Answer C captures this precisely. Answer A contradicts the evidence — raw deny messages are confirmed present in the archive, so the appliance didn't stop generating them. Answer B is self-defeating: if the collector lost connectivity after receiving each message, the raw events wouldn't be stored either, yet the archive confirms they are. Answer D misunderstands SIEM architecture — correlation rules operate after normalization and have no ability to suppress events before collection or archiving occurs. The broader trap this question sets is confusing collection failures with normalization failures. When raw logs exist but normalized data doesn't, always suspect the parser. A practical study tip: map each SIEM pipeline stage (collection → parsing → normalization → correlation) and practice identifying which stage a symptom points to — that framework solves an entire category of SIEM troubleshooting questions.

Question 3

A database team schedules an approved load test that will predictably trigger a high-volume query rule for two hours. Security operations wants to avoid paging analysts during that period but must preserve the activity for later investigation and compliance review.

Which SIEM configuration best meets both objectives?

Pause forwarding from the database and resume collection immediately after the approved test
Temporarily suppress the rule's notifications while continuing to collect and index the events (correct answer)
Disable the database connector and retain only the alerts generated before the test begins
Discard matching events at ingestion while leaving the correlation rule enabled for other data

Explanation: When a SIEM question involves an approved, temporary operational event, your core challenge is balancing alert fatigue reduction against data integrity and compliance. The two requirements here are non-negotiable: stop paging analysts unnecessarily, and preserve everything for later review. That combination tells you immediately that any solution touching data collection is off-limits. Suppressing a rule's notifications — not the rule itself — is exactly what alert suppression or notification muting features are designed for. Option B threads the needle perfectly: analysts aren't paged during the two-hour window, yet every event is still ingested, indexed, and available for forensic review and compliance audits afterward. The correlation rule keeps running silently, capturing context without generating noise. Option A fails because pausing forwarding from the database means a gap in collected data. Even if the test is approved, the raw events never reach the SIEM, leaving a blind spot in your audit trail. Option C is worse — disabling the connector entirely and keeping only pre-test alerts means you have no record of the test activity itself, which directly violates the compliance requirement. Option D is the most dangerous distractor: discarding events at ingestion destroys the data permanently. Leaving the correlation rule enabled doesn't help if the underlying events are gone — you can't reconstruct what happened, and no compliance review is possible. A useful study rule: whenever a question requires preserving data for compliance, immediately eliminate any answer that touches collection, ingestion, or storage. Only solutions that modify alerting behavior — not data flow — can satisfy both objectives simultaneously.

Question 4

A rule runs every five minutes and searches the previous fifteen minutes for malware callbacks. One callback event therefore appears in three consecutive searches, producing three tickets with the same host, destination, and original event identifier. Analysts want one actionable case without losing the underlying evidence.

Which SIEM control is most appropriate?

Stop indexing callback events after the first ticket is created and retain only the rule's alert output going forward
Shorten event retention to five minutes so older callback records age out before the next search window opens
Raise the callback threshold to three events so the three repeated search hits together satisfy a single detection
Deduplicate or group alerts using the event identifier and a suppression interval longer than the search overlap (correct answer)

Explanation: When you see a SIEM question about duplicate alerts from overlapping search windows, ask yourself: does the solution preserve evidence while reducing analyst noise, or does it destroy data to achieve quiet? That distinction separates good alert management from dangerous shortcuts. Here, the overlap is structural — a 15-minute lookback running every 5 minutes guarantees each event appears in three consecutive searches. The clean fix is D: deduplicate or group alerts using a shared event identifier and a suppression window that spans the overlap (at least 15 minutes). This collapses three tickets into one actionable case while the original log events remain fully intact in the index. Analysts get signal without redundancy, and auditors still have the evidence chain. A is dangerous because it stops indexing callback events after the first alert. You lose the raw telemetry itself — not just the duplicate tickets. If the ticket is closed incorrectly or the threat evolves, you have no evidence to re-investigate. Never sacrifice log fidelity for alert hygiene. B shortens retention to five minutes, which would purge the very evidence the SOC needs for investigation and compliance. Retention policies exist to support forensics, not to paper over detection design flaws. C raises the detection threshold to three hits, which means a single callback — a genuine threat — would now go undetected unless it artificially repeats across all three windows. You've turned a detection gap into a policy, potentially letting real malware callbacks slip through. The study tip: on SIEM questions, always favor solutions that manage alert presentation over solutions that alter data retention or detection sensitivity — those trade security for convenience.

Question 5

A SIEM rule alerts on encoded command-line execution. Most alerts come from a signed administrative tool that runs a known script from a controlled path, but attackers could still use other encoded commands. The security team wants fewer false positives without creating a broad visibility gap.

Which tuning approach best preserves the rule's detection value?

Suppress all encoded-command alerts and rely on analysts to find suspicious executions during searches
Exclude every encoded command launched by an account that belongs to an administrative group
Stop collecting command-line events from managed systems where the approved tool is installed
Exclude only the verified signer, script, and controlled path combination while retaining the collected telemetry (correct answer)

Explanation: When tuning a SIEM rule, your goal is surgical precision — reduce noise without sacrificing visibility. The key question to ask is: "Does this change eliminate false positives, or does it create blind spots?" Good tuning narrows the exception to the smallest defensible scope while keeping telemetry intact. Option D achieves exactly this. By excluding only the specific combination of verified signer, known script path, and controlled execution path, you're targeting the one legitimate pattern causing noise. Critically, you're still collecting the underlying telemetry — you've just suppressed that one benign signature. Any attacker using encoded commands who doesn't match all three criteria will still trigger an alert. That's precise tuning with no visibility gap. Option A is essentially giving up. Suppressing all encoded-command alerts and relying on manual hunting removes automated detection entirely, leaving you dependent on an analyst remembering to search at the right time. Option B is dangerously broad — administrative accounts are high-value targets, and attackers who compromise a privileged account would immediately bypass detection. Group membership is not a trustworthy indicator of benign behavior. Option C is the most severe mistake: stopping telemetry collection altogether means you lose the raw data needed for both alerting and retrospective investigation. You can't tune or hunt what you never collected. A useful study pattern here: whenever a tuning question offers an option that stops collection or suppresses by broad identity (like a whole group or account type), treat it as a red flag. Legitimate tuning targets specific, verified combinations, never categories of users or entire data streams.

Question 6

A SIEM enriches login events with network ownership data. A rule lowers the severity of every anomalous login when the source address belongs to a corporate proxy range. An attacker uses stolen credentials through that proxy and then changes privileged account settings, but the resulting alert remains low priority.

Which conclusion best explains the weakness in this alert logic?

Network ownership enrichment supplies context, but proxy membership alone is insufficient evidence that activity is benign (correct answer)
Network ownership enrichment should replace behavioral correlation whenever an address belongs to a managed range
A successful login from a corporate proxy cannot be correlated with later privileged account activity
An enrichment field affects event storage only and therefore cannot validly influence alert severity

Explanation: When a SIEM uses enrichment data to automatically reduce alert severity, you're being tested on a core principle: context reduces uncertainty, but it doesn't eliminate risk. Ask yourself whether a single enrichment attribute — like source IP ownership — is sufficient on its own to conclude that activity is safe. Here, the SIEM assumes that traffic originating from a corporate proxy range is inherently trustworthy. But proxy membership only tells you where the request came from, not who is behind it or what intent they have. A stolen credential used through a legitimate proxy still represents a compromised account. The logic conflates "traffic looks internal" with "traffic is benign" — a classic false equivalence. Answer A captures this precisely: network ownership enrichment provides useful context, but it is not sufficient evidence of benign behavior. The severity reduction is unjustified because it ignores what happens after login, such as privileged account modifications. B is wrong because it inverts good security practice — enrichment should supplement behavioral correlation, not replace it. Dropping behavioral analysis for any managed-range address creates a dangerous blind spot. C is wrong because SIEMs absolutely can (and should) correlate login events with subsequent privileged activity; that's a foundational SIEM capability. D is wrong because enrichment fields routinely and legitimately influence alert severity, routing, and triage — that's a primary purpose of enrichment pipelines. As a study tip, watch for questions where a single benign-looking attribute overrides multi-factor analysis. On security exams, "single attribute → safe" logic is almost always the trap.

Question 7

A newly developed SIEM rule detects a sequence that was not recognized six weeks ago. The organization retained raw logs from that period, but the new rule depends on normalized fields that were not extracted when those logs originally arrived. Investigators want to determine whether the sequence occurred historically.

What must the organization do to support the most reliable retrospective detection?

Apply the rule directly to old alerts because alerts preserve every field from their underlying raw events
Run the rule only on new data because correlation logic cannot evaluate events retained before deployment
Reprocess the retained raw logs with the required parser and replay the resulting events through correlation (correct answer)
Increase current collection rates so the SIEM can infer which historical sequences probably occurred

Explanation: When a SIEM rule depends on normalized fields — structured attributes extracted from raw logs during ingestion — any logs processed before that normalization logic existed will be missing those fields. This means you cannot simply point a new rule at old data and expect it to work; the underlying data structure isn't compatible. Questions like this test whether you understand the full log pipeline: raw collection → parsing/normalization → correlation. The correct path, choice C, is to reprocess the retained raw logs using the updated parser so that the required normalized fields are extracted, then replay those newly structured events through the correlation engine. This reconstructs the data in the format the rule expects, making retrospective detection both possible and reliable. Choice A is wrong because alerts are summaries — they capture information the old rules considered relevant, not every field from the underlying raw event. Normalized fields the old pipeline never extracted won't appear in legacy alerts. Choice B reflects a common misconception: correlation logic itself isn't inherently time-bound. The real constraint is data format, not deployment date. The rule can evaluate historical events — provided those events are properly normalized first. Choice D is a red herring. Increasing current collection rates does nothing to recover or infer what happened six weeks ago. You cannot statistically substitute present-day volume for absent historical evidence in forensic or compliance contexts. Your study takeaway: in any SIEM retrospective scenario, trace the data pipeline — raw logs → parser → normalized events → correlation. If a step was missing historically, you must replay, not infer or substitute.

Question 8

A SIEM rule alerts when one account has failed logins from at least five distinct source IP addresses within a rolling 10-minute window and then succeeds no more than two minutes after the fifth distinct failure. The SIEM receives these events: 09:00 failure from A, 09:02 failure from A, 09:04 failure from B, 09:06 failure from C, 09:08 failure from D, 09:09 failure from E, and 09:11 success from E.

How should the SIEM evaluate this event set?

Do not alert, because the repeated failure from A means six total failures are required before distinct-source counting begins
Alert, because E completes five distinct sources by 09:09 and the success at 09:11 occurs within the two-minute boundary (correct answer)
Do not alert, because the 09:00 failure from A falls outside a 10-minute window ending at 09:09 when the fifth distinct source appears
Alert beginning at 09:08, because that event is the fifth total failure in the sequence and is incorrectly treated as the fifth distinct source

Explanation: When evaluating SIEM correlation rules, you need to track two independent conditions simultaneously: the detection window and the post-trigger time boundary. Don't conflate "total failures" with "distinct-source failures" — these are separate metrics. Here, the rule requires five distinct source IPs within a rolling 10-minute window, followed by a success within two minutes. Walking through the timeline: failures arrive from A (09:00), A again (09:02 — same source, doesn't add a new distinct IP), B (09:04), C (09:06), D (09:08), and E (09:09). That gives five distinct sources — A, B, C, D, E — all within the window 09:00–09:09, which spans exactly 9 minutes. The rule triggers at 09:09. The success from E arrives at 09:11, which is exactly two minutes later, still within the two-minute boundary. Answer B is correct. A is wrong because it invents a rule that doesn't exist — repeated failures from the same source don't delay or reset distinct-source counting. The rule counts IPs, not raw failure events. C is tempting but wrong: the 10-minute window is measured from the first event to the fifth distinct source, which is 09:00 to 09:09 — only 9 minutes, well within the 10-minute limit. D misreads the rule entirely by substituting "fifth total failure" for "fifth distinct source"; the fifth total failure is the D event at 09:08, but D is only the fourth distinct source. On SIEM rule questions, always map each condition in the rule to specific events before evaluating — precision in parsing rule logic is exactly what these questions test.

Question 9

A SIEM should correlate a rare DNS lookup, an endpoint process launch, and a large proxy upload when all three involve the same workstation. DNS logs identify the workstation by short hostname, endpoint logs use a device UUID, and proxy logs use a recently assigned IP address. Each event is searchable, but the composite alert is rarely produced.

Which change most directly addresses the failed correlation?

Create a canonical asset identity that maps hostnames, device UUIDs, and time-bounded IP assignments (correct answer)
Increase the severity of each individual event so all three exceed the alerting threshold independently
Extend retention for all three sources so the events remain searchable for a longer period
Replace the three-source correlation with separate rules that group events only by source type

Explanation: When a SIEM fails to correlate events that clearly belong together, the root cause is almost always an identity resolution problem — the system can't recognize that three different identifiers (a hostname, a UUID, an IP address) all refer to the same asset. That's exactly what this question is testing. The fix is A: building a canonical asset identity — essentially a lookup table that says "short hostname webdev-42, UUID a3f9..., and IP 10.1.2.87 (valid from 9:00–17:00 Tuesday) all mean the same machine." Once the SIEM can resolve disparate identifiers to a single asset record, the correlation rule can fire correctly, because all three events now share a common key to join on. B misses the point entirely. Raising individual event severity doesn't help correlation — you'd just get three separate low-context alerts instead of one meaningful composite alert. Correlation is about relationships, not thresholds. C addresses retention, which matters for long-term investigations, but the scenario describes events that are already searchable. The problem isn't that they disappear too quickly — it's that the system can't link them in the first place. D moves in the wrong direction. Splitting events into source-type silos eliminates cross-source correlation entirely, which is precisely what a SIEM is designed to perform. You'd lose the whole value of multi-source analysis. Study tip: On SIEM and log management questions, if the scenario involves the same asset appearing under different identifiers across sources, the answer will almost always involve identity normalization or asset enrichment — not tuning thresholds or retention policies.

Question 10

A company routes employee web traffic through a shared egress gateway. The SIEM receives firewall logs showing the gateway's public IP address and destination addresses. After a suspicious connection is detected, analysts cannot determine which internal user initiated it.

Which additional collection would most directly enable reliable user attribution during correlation?

Gateway or proxy logs containing timestamped mappings among users, internal addresses, and outbound sessions (correct answer)
Longer retention of firewall events containing the same public source address and destination addresses
More frequent threat-intelligence updates classifying the destination addresses observed by the firewall
Lower alert thresholds for outbound connections originating from the shared public source address

Explanation: When analysts can't trace a suspicious connection back to a specific user, they're facing a user attribution gap — a core SIEM correlation challenge. The question tests whether you understand what data type closes that gap, not what tools process it faster or louder. The root problem is that the firewall only sees the shared gateway's public IP — it can't distinguish which internal user or device initiated the session. To attribute a connection, you need a record that links an internal identity (username or private IP) to an outbound session at a specific timestamp. That's exactly what A provides: gateway or proxy logs that map users, internal IPs, and outbound sessions together. With these, analysts can join the firewall event (destination + timestamp) to the proxy log (user + internal IP + timestamp) and pinpoint who made the connection. This is a direct, structural fix to the attribution problem. B is wrong because retaining the same firewall logs longer doesn't add new data fields — you still only see the shared public IP and destination. More of the same incomplete record doesn't close the attribution gap. C is a red herring: better threat-intelligence classification tells you what the destination is (malicious, benign, etc.) but reveals nothing about who connected to it. D lowers alert thresholds, meaning you'd generate more alerts — but more alerts on data that already can't identify the user only increases noise without improving attribution. A useful pattern to remember: when a question asks about attribution or traceability, focus on which log source maps identities to activity, not on retention, alerting, or enrichment of existing incomplete data.