The Security Operations Center is the most common entry point to a security career. These questions focus on alert triage, investigation methodology, SIEM fluency, and the judgment calls that separate a strong L1 from a weak one.
An IDS (Intrusion Detection System) passively monitors traffic and generates alerts when suspicious patterns are detected. It doesn't interfere with traffic — it observes and reports.
An IPS (Intrusion Prevention System) sits inline in the traffic path and can actively block or drop malicious traffic in real time. Most modern NGFWs combine both functions.
The tradeoff: IPS adds latency and can cause false-positive blocks that disrupt legitimate traffic. IDS creates more alert noise for analysts to review but carries no risk of accidental blocking.
A SIEM (Security Information and Event Management) collects, normalizes, and correlates logs from across the environment to surface alerts and support investigations.
A SOAR (Security Orchestration, Automation and Response) automates and orchestrates the response to those alerts — running playbooks, enriching alerts with threat intel, and taking containment actions like isolating hosts or blocking IPs.
Think of SIEM as the detector and SOAR as the responder. In practice, SOAR ingests alerts from the SIEM and reduces the manual triage burden on analysts.
A false positive is a benign activity that triggers a security alert. Too many false positives cause alert fatigue, which is one of the primary reasons real attacks go undetected — analysts start ignoring or auto-closing alerts without reviewing them.
To reduce them: tune detection rules against your specific environment baseline, use allowlists for verified safe activity, add asset context (a critical server behaving unusually matters more than a dev machine), and regularly retire noisy rules that haven't generated a true positive in a meaningful timeframe.
Triage first: Who received it? Did they open it, click any links, or enter credentials? Establish what action was taken before diving into technical analysis.
Analyze the email: Pull headers and check SPF/DKIM/DMARC results, the sending IP reputation, and whether the domain is a typosquat or was recently registered. Run any URLs through sandbox analysis (URLScan, Browserling).
If the user clicked: Check EDR for browser process activity, any unusual child processes, or outbound connections to unknown IPs. Check identity logs for sign-in anomalies (new location, new device, MFA bypass).
If credentials were entered: Force a password reset and revoke all active sessions immediately — don't wait to confirm misuse first.
IOCs are observable artifacts that suggest a system may have been compromised — IP addresses, domains, file hashes, registry keys, email senders, URLs. They're fast to share and easy to block at the tool level.
The limitation: IOCs are ephemeral. Attackers can rotate a C2 IP in an hour and recompile malware to change its hash in minutes. David Bianco's Pyramid of Pain captures this — the higher you go (hash → IP → domain → TTPs), the more durable your detection and the harder it is for the attacker to evade it. TTP-based detection is more work to build but far more resilient.
MITRE ATT&CK is a knowledge base of adversary tactics, techniques, and procedures (TTPs) observed in real-world attacks. It's organized into Tactics (the goal — e.g., Persistence, Lateral Movement) and Techniques (the method — e.g., T1078 Valid Accounts).
Day-to-day SOC use: mapping alerts to ATT&CK techniques to understand where you are in an attack chain, identifying coverage gaps in your detection stack (which techniques have no detections?), and using a shared vocabulary when escalating to or communicating with threat intel and IR teams.
Lateral movement is when an attacker, having compromised one host, pivots to other systems on the same network to expand access toward their target (typically domain admin, data, or business systems).
Common Windows techniques:
SMB/Windows Admin Shares (T1021.002) — using tools like PsExec to execute commands on remote hosts over SMB using legitimate admin credentials.
Pass-the-Hash (T1550.002) — using a captured NTLM hash to authenticate to other systems without knowing the plaintext password. The hash is the credential.
Authentication logs: Windows Security Event 4624 (successful logon) and 4625 (failed logon). Azure AD / Entra sign-in logs for cloud accounts. VPN gateway logs for remote access sessions.
MFA provider logs: Was MFA challenged? Passed? Bypassed? Was there a suspicious number of push requests before approval?
EDR telemetry: What happened on the endpoint after the logon — any process execution, file access, or network connections?
Key indicators to look for: unusual source IP or geolocation, new device fingerprint, logon outside business hours, multiple failures before success, or unusual actions taken immediately after login.
Use STAR format: Situation → Task → Action → Result. Keep it to about 90 seconds.
The key signal the interviewer wants: that you have a triage methodology. Strong answers describe asking for help or escalating when needed, documenting what was deprioritized and why, and communicating clearly to stakeholders about any delays. The story should show you made a deliberate decision, not that you just "worked faster."
If you're entry-level without direct work experience, a lab or CTF scenario works fine — "During a timed CTF, I had three partially-completed challenges with 30 minutes left and had to decide which to finish."
Specific sources matter here. Weak answer: "I follow security news." Strong answer: named sources and how you actually use them.
Good examples: CISA advisories, Microsoft MSTIC blog, Mandiant and CrowdStrike threat intel reports, vendor disclosure feeds, NVD for CVE tracking with EPSS scores for prioritization, SANS Internet Stormcast podcast.
Bonus signal: participation in CTFs, home lab exercises, involvement in ISAC sharing groups, or contributions to threat intel communities. Anything that shows you engage actively rather than passively reading headlines.
Use STAR format. The key elements: you adapted your language to the audience, you focused on business impact rather than technical mechanics, and the person you were talking to could act on what you told them.
Example framing: "I told a manager their team member's account had been compromised. Instead of explaining the NTLM hash chain, I said: an attacker has the equivalent of a working key to this account — we need to lock it and change the locks right now."
Avoid answers where the punchline is "they still didn't understand me." Own the communication outcome.
Show triage discipline, not just raw throughput. Strong answers describe: severity-first ordering, asset criticality context (an alert on a domain controller outranks the same alert on a contractor laptop), suppressing known-good noise versus tuning out real signals, and escalation criteria for when to bring in T2.
Also important: documenting anything that gets deferred so it doesn't fall through the cracks, communicating queue status to the team, and recognizing when the alert volume itself is anomalous and might indicate a coordinated event.
Confirm first: Verify the IP against threat intel (VirusTotal, your TIP, SIEM enrichment). Confirm it's a true positive before acting.
Identify the process: Check EDR — what process is making the connection? A browser reaching a known-bad IP is very different from cmd.exe or PowerShell doing so.
Contain: Isolate the host to sever the C2 channel. Preserve a memory dump before isolation if possible — in-memory malware disappears when the host loses connectivity and reboots.
Investigate scope: Check SIEM for correlated events — what did this host do in the 24 hours before and after the alert? Look for lateral movement to other hosts, credential dumping, data staging.
Escalate and document: Open a ticket, escalate to T2 or IR team, document the full timeline with timestamps.
Triage the action: When did they click? What site did it open? Did they enter credentials, download a file, or run anything?
Analyze the email and URL: Pull headers. Run the URL through sandbox analysis. Check domain registration date and category.
Check EDR: Was the browser the only process involved, or did a download trigger execution? Any unusual child processes or outbound connections after the click?
Check identity logs: Any recent sign-ins from new locations or devices? Any MFA push requests the user didn't initiate?
If credentials were entered: Force a password reset and revoke all active sessions immediately — don't wait to confirm misuse. The cost of being wrong about resetting is much lower than the cost of a compromised account sitting open.
Characterize the attack: Is it a single source IP (brute force) or distributed sources (password spray)? The response differs.
Check threat intel: Is the source IP known-malicious? Part of a Tor exit node list? A commercial proxy?
Check for success: Did any of those 500 attempts result in a successful logon? This is the most important question. If yes, shift immediately to account takeover response.
Identify the account: Human user vs. service account? Admin vs. standard? Criticality determines urgency.
Act: Block the source IP at the firewall, temporarily lock the account, notify the account owner, and check for any actions taken during a successful logon window if one occurred.