All jobs / Cybersecurity

SOC / Blue Team interview questions

SOC / Blue Team questions a Cybersecurity can be asked, from first job to senior. Open one to see the strongest answer and why it works.

  1. What is a SIEM for, and what makes one useful rather than just expensive?

    The strongest answer: It collects logs from many systems so you can correlate and alert across them; it earns the cost only when the right sources are onboarded and the alerts have someone who acts on them

    Why it works: Right — sources, tuned detections and a response process. Without those it is an expensive log bucket.

    • Collect, correlate, alert, act.
    • Onboard the sources that matter.
    • Tune rules to your estate.
    • An unread alert is not detection.
  2. Someone clicked a fake login and typed their password. What do you do first?

    The strongest answer: Reset the password, revoke sessions, check MFA and mail rules, and treat it as an incident — I do not start with a lecture

    Why it works: Exactly. Contain first. Teaching comes after the sessions are dead.

    • Reset and revoke.
    • Check MFA, mail, grants.
    • Contain before the lecture.
    • Do not shame in public.
  3. The SOC queue is 4,000 “impossible travel” alerts a week. What do you do?

    The strongest answer: Tune or drop the noisy rule, measure true positives, and give analysts a playbook — I do not hire people to click Dismiss

    Why it works: Exactly. Detection is a product. Fatigue is a vulnerability. Hidden queues are a red flag.

    • Tune or kill noisy rules.
    • Measure true positives.
    • Write the playbook.
    • Do not hide the queue.
  4. A threat feed gives you a list of IP addresses and file hashes. What are those worth, and what is worth more?

    The strongest answer: They are indicators — cheap to block and quick to go stale, because they are easy to change. Behaviour and technique last longer, so that is what I want most detections written against

    Why it works: Exactly — indicators perish, techniques do not. Use both, but spend the detection effort on behaviour.

    • Indicators perish; behaviour persists.
    • Block and hunt with indicators.
    • Write detections on techniques.
    • Vet a feed before auto-blocking.
  5. What is in a 15-minute phishing playbook?

    The strongest answer: Revoke, reset, check rules and grants, tell the people who must know — a card, not a 40-page IR novel

    Why it works: Exactly. Containment steps a tired person can run. Novels and blame lose the quarter-hour.

    • Revoke and reset.
    • Mail rules and OAuth grants.
    • Notify who must know.
    • No blame list on the card.
  6. How do detections survive a noisy week?

    The strongest answer: Detections as code: review, test on known-good and known-bad, and an owner — a GUI full of unsigned rules is folklore

    Why it works: Exactly. Same discipline as product code. News-driven piles and private notebooks fail the next holiday.

    • Review and test detections.
    • Name an owner.
    • Do not pile rules from the news.
    • Do not turn the SIEM off.
  7. At 2am you are asked one question about a suspected compromise of a web application: did they get in, and what did they reach?

    Which logs do you want, and in what order?

    The strongest answer: Authentication and session events first, then application access logs for that account, then outbound network and database query logs — a timeline around one identity rather than reading everything

    Why it works: Right — an identity-anchored timeline answers both halves of the question and shows what you cannot yet prove.

    • Anchor on one identity.
    • Authentication, then access, then egress.
    • Build a timeline, not a pile.
    • Write down what stays unproven.
  8. What is a tabletop for, if not a performance?

    The strongest answer: To find the missing owner, the missing log, and the missing comms path — one page of gaps, not a scripted win

    Why it works: Exactly. Tabletop is a test of the plan. Scripted wins teach nothing.

    • Find missing owners and logs.
    • Find the comms path.
    • Write the gaps.
    • Do not script a win.
  9. How do you use MITRE ATT&CK so that it changes what you detect, instead of becoming a wall chart?

    The strongest answer: Take the techniques that fit our estate and threats, check which have a real detection on a real log source, and turn the gaps into a short backlog — a rule that merely mentions a technique is not coverage

    Why it works: Exactly — scoped to your estate, tied to log sources, and honest about what each rule really catches.

    • Scope the matrix to your estate.
    • One technique, one real log source.
    • Gaps become a small backlog.
    • Do not report coverage percentages.
  10. How do you treat the SOC like a product?

    The strongest answer: Users (analysts), SLOs (time-to-triage, true-positive rate), and a backlog of detections — not a room that only grows seats

    Why it works: Exactly. SLO and backlog. Seats and magic AI without tuning are how queues die.

    • SLO: triage time and precision.
    • A detection backlog.
    • Seats last.
    • Do not reward dismissals.
  11. You are asked to fund a threat-intelligence function. What must it produce for you to keep paying for it?

    The strongest answer: Decisions we would not otherwise make — which detections to write, which assets to harden first, which supplier to question — tied to threats that plausibly target our sector and our stack

    Why it works: Right — intelligence is judged by the decisions it changes, not by the volume of reporting.

    • Judge intel by decisions changed.
    • Tie reporting to our own stack.
    • Every report names an action.
    • News is not intelligence.
  12. How do you log enough to investigate without building a people-surveillance pile?

    The strongest answer: Log security-relevant events, minimise content, purpose-limit access, and expire — I do not keep keystrokes “in case”

    Why it works: Exactly. Purpose, minimum, access, retention. Keystrokes and mailbox feeds are a different product — and a legal one.

    • Security events, not keystrokes.
    • Minimise and expire.
    • Purpose-limit who can read.
    • Do not disable logging to hide.
  13. What must a ransomware tabletop prove besides “we have backups”?

    The strongest answer: That restores work, that identity can be rebuilt, and who speaks — backups you have never restored are a rumour

    Why it works: Exactly. Restore, identity, voice. Pay/no-pay is a legal call you prepare, not a cheer. Brochures are not drills.

    • Prove restores.
    • Prove identity rebuild.
    • Name the spokesperson.
    • Backups without a restore are rumours.
  14. A director asks “what percent of attacks do we detect?” What do you refuse?

    The strongest answer: A made-up percentage — I will show ATT&CK coverage we actually test, and the gaps we have not tested, not a vanity pie

    Why it works: Exactly. Coverage of tested techniques. Invented percents are an honesty violation.

    • Show tested techniques.
    • Show untested gaps.
    • No invented percent.
    • No logo pies.
  15. A Sev-1 was a missed IDOR. How do you run the review?

    The strongest answer: Which default would have made the miss impossible, and one road change — I do not run a hunt for the last reviewer

    Why it works: Exactly. Make the miss hard. Last-reviewer hunts and ocean mandates teach fear, not a road.

    • Change the default.
    • One owned road change.
    • No last-reviewer hunt.
    • No ocean of Friday tests.