SIEM & SOAR Interview Questions

A SIEM platform aggregates and correlates log and event data from many sources — firewalls, endpoints, servers, applications — in near-real-time to detect and alert on suspicious activity, such as a pattern spanning multiple systems that no single log source would reveal alone. It is a distinct category from patch management, endpoint encryption, and identity/access provisioning tools.

IOC stands for Indicator of Compromise. It is a piece of forensic evidence — such as an IP address, domain name, file hash, or URL — that signals that a system may have been compromised or that malicious activity has occurred. IOCs are used to populate detection rules and threat-intel feeds in a SIEM to trigger alerts when matched.

When a new SIEM alert fires it automatically creates a ticket in our case-management system and assigns a default priority based on the alert rule's configured severity, so the single analyst never manually sorts raw alerts — they simply pick up the next highest-priority ticket. Duplicate or related alerts from the same source within a short window are grouped into one case to prevent the queue from flooding. The analyst then follows a structured triage decision process: (1) review the SOAR-enriched context attached to the ticket, (2) compare the alert against documented known-false-positive patterns (e.g., approved backup scanner triggering a port-scan rule), (3) classify the alert as high-confidence true positive, low-confidence/suspicious, or false positive. High-confidence true positives are escalated immediately to incident response; suspicious alerts get a deeper manual investigation with correlated log queries; false positives are closed with a documented reason. SOAR automation is used selectively with explicit justifications: it auto-enriches every new ticket with threat-intel lookups (hash reputation, IP reputation, user context) because doing this manually on every alert would consume the analyst's entire shift; it also auto-closes low-severity alerts that match a previously documented false-positive pattern, accepting the trade-off that a novel attack variant matching the same pattern could be missed — this risk is mitigated by periodically reviewing auto-closed tickets. The analyst does NOT auto-isolate endpoints because at this company size the blast radius of a wrong isolation (cutting off an executive's laptop) outweighs the speed benefit, so isolation remains a human decision. For every ticket, the final disposition (true positive, false positive, escalated) and all actions taken are recorded in the ticket itself. Critically, these recorded dispositions feed back into the workflow: accumulated false-positive data is reviewed monthly to tune SIEM detection rules and expand the SOAR auto-close pattern library, progressively reducing noise over time without losing detection coverage.

A correlation rule is a set of defined conditions and logic that a SIEM evaluates against ingested events. When incoming events match the rule's criteria—such as a threshold of failed logins within a time window—the SIEM generates a consolidated alert for analysts to investigate.

A SIEM aggregates, correlates, and alerts on log/event data; a SOAR platform picks up from an alert and orchestrates the response — running playbooks that enrich, contain, or remediate an incident with little or no human intervention. Many vendors ship both under one product, but they are functionally separate layers: detection versus orchestrated response.

Splunk, IBM QRadar, and Microsoft Sentinel are established SIEM platforms that ingest, normalize, and correlate log data to generate security alerts. Metasploit is an exploitation framework and Terraform is an infrastructure-as-code provisioning tool — both widely used in their own domains, but neither is a SIEM.

True. An Indicator of Compromise is a forensic artifact — a malicious file hash, IP address, or domain — that suggests a system may already be compromised, sourced from threat-intel feeds or prior incident findings. SIEM/threat-intel integrations commonly match incoming log data against IOC feeds automatically, raising an alert without an analyst having to manually recognize a known-bad indicator.

Alert fatigue is the desensitization that happens when analysts are exposed to a high volume of low-fidelity or false-positive alerts, causing them to start missing or deprioritizing genuine incidents buried in the noise. Two concrete mitigations: tuning correlation rules — raising thresholds, scoping to the right source and time window, suppressing known-benign patterns — to cut the false-positive rate at the source; and using SOAR playbooks to auto-triage or auto-close low-confidence alerts and enrich the rest before a human ever sees them, so analyst attention only goes to alerts that already cleared an automated first pass.

A publicly maintained, freely available knowledge base of real-world adversary tactics (the "why" — the attacker's goal, like Initial Access or Lateral Movement) and techniques (the "how" — the specific method used to achieve that goal), compiled from observed intrusions. SOC and detection-engineering teams use it as a common vocabulary to map existing detections and correlation rules to specific techniques and identify coverage gaps.

Step 1 — Decompose the threat report: Analysts read the report and extract both IOCs (sender domains, subject-line patterns, destination URLs) and behaviors (e.g., multiple failed logins followed by a successful login from a new geo within 10 minutes). Each item is mapped to a log source we already ingest (email gateway, proxy, IdP logs) and translated into a SIEM correlation rule. For example, a phishing domain becomes a proxy-log query for any internal host visiting that domain; a login-anomaly behavior becomes a correlation across IdP and geolocation enrichment.

Step 2 — Validate the rule: Before enabling it in production, the analyst runs the rule query against the last 30 days of archived logs. They confirm it fires on any known-malicious samples seeded into the test environment (true-positive check) and count how many times it would have fired on historical benign traffic (false-positive baseline). If the FP rate exceeds an agreed threshold (e.g., more than 5 false hits per day), the rule is not yet production-ready.

Step 3 — Tune and document: The analyst adds exclusions for known-safe internal scanners, adjusts thresholds (e.g., require 5+ failed logins instead of 1), and creates allowlist entries for legitimate bulk-mail senders that might trip the domain rule. A use-case document is written that links the rule ID to the original threat report so the detection's intelligence lineage is always traceable.

Step 4 — IR lifecycle handoff: The rule is deployed at an agreed severity and category (e.g., Medium for a proxy hit on a phishing domain, High if combined with credential submission; category 'Phishing — Credential Theft'). When it fires, the Tier-1 analyst follows the documented triage steps: verify the alert is not a known false positive, check whether the user submitted credentials, and escalate to IR if credential compromise is confirmed. The IR team then follows the standard containment and eradication playbook. The use-case owner reviews alert performance weekly for the first month, retires or revises the rule when the campaign is no longer active in threat feeds, and archives the documentation for post-incident review.

Stage 1 — Ingestion and extraction (fully automated): When a user reports an email, the SOAR playbook parses the message and extracts all indicators: sender address and domain, all URLs (including those behind redirects), attachments with their hashes, and relevant headers (SPF, DKIM, DMARC results). Each indicator is stored as a structured artifact in the incident record.

Stage 2 — Enrichment (fully automated): The playbook sends each indicator to enrichment sources in parallel: the sender domain and URL reputations are checked against threat-intel feeds (e.g., VirusTotal, internal denylist); attachments are submitted to a sandbox for detonation; domain age and DNS records are queried. Results are appended to each artifact. If a sandbox result is pending, the playbook waits up to a configured timeout (e.g., 5 minutes) before proceeding with whatever data is available.

Stage 3 — Triage decision logic (fully automated): Based on enrichment results, the playbook routes to one of three branches:

• Benign: All indicators return clean reputation, sandbox finds no malicious behavior, and the sender domain is well-established (e.g., domain age > 2 years, valid DMARC). The playbook auto-closes the ticket and sends a courtesy reply to the user.
• Suspicious: At least one indicator returns a low-confidence malicious flag or the sandbox result is inconclusive. The playbook assigns the ticket to a Tier-1 analyst queue for manual review and does not take containment action.
• Confirmed malicious: One or more indicators return a high-confidence malicious reputation, or the sandbox confirms malicious behavior (e.g., credential-harvesting page, malware execution). The playbook proceeds to Stage 4.

Stage 4 — Containment (mixed automation): For confirmed-malicious emails, the following actions are taken:

• Auto-executed: Search and purge the email from all mailboxes where it was delivered (using the email gateway or mail platform API), and block the sender domain/IP at the email gateway.
• Human-gated: If enrichment indicates a user submitted credentials (e.g., a login to the phishing URL was detected in proxy logs), the playbook drafts — but does not execute — actions to disable the user's account and revoke active sessions. An alert is sent to the IR team with a one-click approval; the actions execute only after approval.

Stage 5 — IR lifecycle integration (fully automated): The playbook creates an incident ticket in the IR ticketing system, links all enrichment data and actions taken, and notifies the IR team via the team's communication channel for confirmed-incident cases. Every automated and human-approved action is logged with a timestamp and actor for post-incident review. If the playbook auto-closed the ticket as benign, a summary is still logged for trend analysis. Weekly metrics (reports received, triage outcomes, containment times) are generated for the SOC manager to assess playbook effectiveness and tune thresholds.

A basic SIEM correlation rule is defined by three core components: the logical condition that events must satisfy, the time window within which matching events must occur, and a threshold that specifies the minimum count of matching events needed to trigger an alert.

MITRE ATT&CK is a publicly maintained knowledge base of real-world adversary tactics (the attacker's goal) and techniques (the specific method used to pursue it), compiled from observed intrusions. SOC and detection-engineering teams plot their existing detections against the matrix to find exactly which techniques have coverage and which don't, turning vague preparedness questions into a concrete, technique-by-technique gap analysis.

Tier 1 SOC analysts handle initial triage of incoming alerts against documented playbook criteria, follow runbooks for first-line response, and escalate confirmed or ambiguous incidents to Tier 2. Proactive threat hunting and owning detection-engineering/correlation-rule authoring require deeper investigative expertise and are typically Tier 3 responsibilities.

False. Most production SOAR playbooks are deliberately hybrid: lower-risk steps like alert enrichment run fully automated, while higher-impact actions such as isolating a host or disabling an account commonly pause for explicit analyst approval before executing. Fully automated end-to-end response is one supported mode, not the only one — the human-in-the-loop approval step is a standard pattern.

Lines 3-4 — the mapping assigns raw.dest_ip to the normalized src_ip field and raw.src_ip to dest_ip, swapping the two fields

The SIEM ingests and normalizes logs from firewalls, endpoints, identity providers, and applications, then runs correlation rules against that combined stream to raise an alert — for example, several failed logins followed by a success from an unusual location. That alert triggers a SOAR playbook, which automatically enriches it (looking up the source IP against threat-intel feeds, pulling the user's recent activity and asset context), can auto-triage or close low-confidence noise, and either executes a low-risk automated action (opening a ticket, tagging the asset) or pauses for analyst approval before a higher-impact containment step like disabling the account or isolating the host. The net effect: the SIEM detects, and the SOAR standardizes and accelerates the response.

The SANS incident response lifecycle runs in a fixed order: preparation (before anything happens), identification (confirming an incident is real), containment (limiting spread), eradication (removing the root cause), recovery (restoring normal operation), and lessons learned (a post-incident review). Containment has to precede eradication — stopping the spread before removing the cause — because eradicating too early while another foothold remains can look like a fix while leaving the attacker still present.

IOC confidence decay is the principle that an indicator's value as a detection signal erodes over time. Attackers rotate infrastructure (domains, IPs, TLS certificates) frequently, so a hash or IP that was high-fidelity on day one becomes low-fidelity or noise-generating after weeks or months. A mature detection pipeline assigns each IOC a confidence score that decays on a schedule (linear, exponential, or stepwise) from its first-seen or last-seen timestamp, and detection rules either suppress or de-weight matches once the score drops below a threshold. Failing to model decay causes stale IOCs to produce false positives, inflate alert volume, and mask genuinely new threats — the classic 'indicator fatigue' problem. Best practice is to pair every atomic IOC (IP, domain, hash) with contextual enrichment (e.g., ASN reputation, domain age, sandbox verdict) and to promote high-confidence behavioral patterns (e.g., specific command-line sequences, registry modifications) over purely atomic indicators, since behaviors have a much longer useful lifetime.

The correct ATT&CK mappings are T1218.005 (Signed Binary Proxy Execution: Mshta) for mshta.exe loading a remote HTA, T1566.001 (Phishing: Spearphishing Attachment) because winword.exe as the parent process indicates a malicious document, and T1140 (Deobfuscate/Decode Files or Information) for certutil.exe -decode processing a base64 payload. No PowerShell (T1059.001) or LSASS credential dumping (T1003.001) appears in the described behavior.

A correlation rule in a SIEM differs from a simple threshold rule in that it joins events from multiple log sources or event types based on a shared entity (such as a user, IP address, or hostname) and a temporal or logical relationship, rather than merely counting events of a single type.

Example: correlating a VPN login event from the VPN gateway log with a privileged shell command from the endpoint EDR on the same user within 10 minutes — neither event alone is suspicious, but their correlation may indicate lateral movement.

Line 2 — grouping only by user, without also scoping by source host/IP and a bounded time window, sums scattered failures for a busy account across the whole fleet into one count, instead of looking for many failures from a single source in a short window, which is the actual brute-force signature

True. The MITRE ATT&CK Navigator automatically computes and displays an aggregate score on a parent technique from its scored sub-techniques, even when no explicit score is placed on the parent technique itself. This roll-up behavior lets detection-engineering teams score granular sub-techniques and still see composite coverage at the technique level without redundant manual scoring.

The canonical Intelligence Cycle sequence is: Planning & Direction → Collection → Processing & Exploitation → Analysis & Production → Dissemination → Evaluation & Feedback. Requirements are defined first (PIRs), raw data is then gathered, processed into structured form, analyzed into intelligence products, disseminated to consumers and defensive tooling, and finally feedback closes the loop to refine the next cycle's priorities.

The Lockheed Martin Cyber Kill Chain stages in canonical order are: Reconnaissance → Weaponization → Delivery → Exploitation → Installation → Command and Control (C2) → Actions on Objectives. Each stage is a prerequisite for the next: the attacker probes the target, builds a weaponized payload, delivers it, executes the exploit, installs persistence, establishes C2, and finally carries out their mission objective.