1. Courses
  2. Cybersecurity
  3. Defensive Security: SOC, Detection and Response
  4. Stop 1

30 minIntermediate

Inside a SOC

A security operations centre (SOC) is the team that watches a company's systems, catches attacks early and contains them before damage spreads. This lesson walks you through what a SOC does, who does it, the tools they use and the numbers that tell them how they are doing, by spending a shift inside Mangrove Market's small SOC. By the end you will read a job advert for a SOC analyst and know exactly what the work is.

By the end you can

  • Describe the SOC loop: detect, triage, investigate, respond and improve
  • Name the roles and tiers, and follow how one alert flows between them
  • Say what a SIEM, an EDR, a SOAR, a case system and a threat-intel feed are each for
  • Read the core SOC measures and explain how each one can mislead you
  • Tell an in-house SOC from a managed one, and place ATT&CK, the kill chain and the OODA loop

The everyday picture

Picture the security desk of a large building at night. Dozens of camera feeds fill a wall of screens. A guard cannot stare at every feed at once, so motion sensors raise a light when something moves on a feed. A junior guard checks each light: a cat on the loading dock is waved away in seconds; a person trying a locked door gets a closer look. If it looks real, the junior calls a senior guard, who pulls up the last hour of that camera, checks the door logs and decides whether this is a break-in. If it is, the shift supervisor runs the response: lock the floor, call the owner, keep a written log of every step.

A SOC is that desk for a company's computers. The camera feeds are logs from apps, laptops, the network and the cloud. The motion sensors are detection rules that raise an alert. The junior guard is Tier 1 triage, the senior is Tier 2 investigation, and the supervisor's response plan is incident response. The whole point is the same: most lights are nothing, a few matter a great deal, and the job is to tell them apart fast and act before the intruder reaches anything valuable.

What a SOC actually does

A SOC is not a product you buy; it is a function made of people, process and tools, running around the clock. Its work is a loop with five steps that never really stops:

  • Detect. Collect logs from everywhere and run rules over them so that suspicious activity turns into an . You met where these logs come from in Thinking like an attacker, and the next lesson, Logs that matter, goes deep on them.
  • Triage. Look at each alert quickly and decide: harmless, needs more work, or raise it. Most alerts are closed here.
  • Investigate. For the ones that survive triage, gather evidence and work out what really happened and how far it went.
  • Respond. If it is a real incident, contain it, remove the attacker and recover, keeping a record the whole time.
  • Improve. Feed what you learned back into better rules and fewer blind spots, so the same thing is caught faster next time.

The last step is what separates a SOC that gets better from one that drowns. Every closed alert is a chance to ask "should this have fired at all?" and "what did we miss?". Without that loop, a SOC answers the same false alarms forever and still misses the real attack.

Identity logins Endpoint EDR Network traffic Cloud audit SIEM collect, correlate Alert queue Analysts triage Investigate, respond keep a record tune rules
The SOC pipeline. Logs from four kinds of source flow into a SIEM that correlates them into alerts; analysts triage the queue, investigate and respond, and what they learn flows back as tuned rules, so the next attack is caught sooner.

Quick check

A Mangrove rule has fired 300 times this week, and every single one turned out to be a harmless scheduled backup job. What should the SOC do?

Roles, tiers and how an alert flows

A SOC sorts its work by how hard and how rare it is. The names vary between companies, but the shape is almost always the same.

  • Tier 1, triage analyst. Works the alert queue. For each alert, gathers the quick context and gives a verdict in minutes: false positive (close it, with a note), or real enough to escalate. The skill is speed with good judgement, not deep investigation.
  • Tier 2, investigation analyst. Takes escalated alerts and digs in: pulls the full history, pivots across logs, works out what happened and how far it spread, and decides whether this is a true incident.
  • Tier 3, threat hunter and detection engineer. Looks for attackers no rule caught (Threat hunting), and writes and tunes the detection rules the whole SOC runs on (Writing detections). This is the senior, creative end.
  • Incident responder. Leads the containment and recovery when an incident is declared (Incident response). In a small SOC this is Tier 2 and Tier 3 wearing a different hat; in a large one it is a separate team.
  • Threat-intelligence analyst. Tracks which attackers target companies like yours and what they do, and turns that into things to look for. In a small SOC this is a feed everyone reads, not a person.
  • SOC lead or manager. Owns the queue, the shift rota, the measures and the relationship with the rest of the business.

A single alert flows through these roles like water finding the lowest path. Most never leave Tier 1. The few that do get heavier attention at each step, and only a handful reach a declared incident. Each tier owns a different decision, and that is the thing to remember: Tier 1 decides "is this worth a closer look?", Tier 2 decides "is this a real incident, and how big?", and incident response decides "what do we do about it right now?".

Tier 1 triage verdict in minutes Close false alarm most escalate Tier 2 investigate scope and evidence Close benign real attack Incident response contain, recover lessons Tier 3 detections hunt, write rules new rules
Each tier owns one decision. Most alerts close at Tier 1, fewer at Tier 2, and only real attacks reach incident response. Tier 3's hunting and detection work feeds new rules back to the start, so the pipeline keeps improving.

Quick check

A Tier 1 analyst sees an alert for a store manager signing in from two cities an hour apart. They are not sure if it is real. What is the right move?

The core tools, and what each is for

You will see the same handful of tools in almost every SOC. You do not need to run them yet; you need to know what job each does, because job adverts list them and alerts come from them.

ToolWhat it is for
The log warehouse and rule engine. Collects logs from everywhere, lets you search them, and raises alerts when a rule or a correlation across sources matches.
The eyes on laptops and servers. Records what programs run, what files change and what connects out, raises its own alerts, and can isolate a machine on command.
The automation layer. Runs repeatable steps for you: gather the context for an alert, open a ticket, disable an account, so analysts spend time on judgement, not clicking.
Case or ticket systemThe record. Every alert, investigation and incident lives here with its timeline, evidence and who did what, so nothing is lost and handovers work.
Threat-intel feedThe outside view. A stream of known-bad addresses, file fingerprints and attacker techniques to match against your logs and to tell you what to look for.

A useful way to hold them together: the EDR and other sensors watch, the SIEM gathers and correlates, the SOAR does the repetitive work, the case system remembers, and threat intel tells you what is worth watching for. None of them is the SOC. They are the instruments; the analysts and the process are the SOC.

Quick check

Mangrove wants that impossible-travel alert to automatically pull the account's recent logins, the device it used and its location history, and attach them to a ticket before an analyst even opens it. Which tool does that work?

The measures, and how each one lies

SOCs are judged by a few numbers. You should know them, and know how each can be gamed or can mislead, because a number chased blindly makes the SOC worse.

  • Mean time to detect (MTTD). From when an attack starts to when the SOC notices. Lower is better. It lies when you only measure the attacks you caught; the ones you never saw are not in the average.
  • Mean time to respond (MTTR). From alert to contained. Lower is better, but you can shrink it by closing alerts fast without really handling them, which trades a good number for real risk.
  • Dwell time. How long an attacker was inside before being found. The honest version of MTTD, and the one that hurts: industry reports still measure serious intrusions in weeks.
  • False-positive rate. The share of alerts that were harmless. High rates burn analysts out and hide real alerts in the noise. But driving it to zero by loosening rules just means you stop catching things.
  • Alert volume per analyst. How many alerts each person must handle per shift. Past a point, quality falls and misses rise, however good the people are.

Two traps matter most. First, an average hides its worst cases: an MTTR of "20 minutes" can be mostly two-minute auto-closes and a few alerts that sat for a day, and the day-long one is the one that hurt. Look at the slowest tenth, not just the mean. Second, every target can be met by doing the wrong thing. The real goal is not a pretty dashboard; it is that real attacks are caught and contained before they cause harm. The measures are there to start that conversation, and burnout is the one that quietly breaks a SOC: tired analysts working a flood of false positives miss the real alert, so a healthy false-positive rate and alert volume are safety measures, not comfort.

Quick check

A SOC lead proudly reports that mean time to respond dropped from 40 minutes to 8 this quarter. What should you ask before celebrating?

In-house or managed, and the frameworks that organise the work

Not every company runs its own 24/7 SOC; it is expensive and hard to staff. The common choices are an in-house SOC (your own people and tools), a managed SOC or MSSP (a provider watches your alerts, often just forwarding the serious ones back to you), and MDR, managed detection and response, where a provider also investigates and takes some response actions on your behalf. Many companies, Mangrove included, run a hybrid: a small in-house team during the day and a provider covering nights and weekends. The trade is control and context versus cost and coverage: your own team knows your systems, a provider gives you round-the-clock eyes you could not afford to hire.

Three shared frameworks give the work a common language, so a Mangrove analyst and an outside provider can describe the same attack the same way.

  • is the shared dictionary of attacker techniques, grouped by the attacker's goal (initial access, persistence, exfiltration, and so on). Detections and hunts are mapped to its technique IDs, which is how a SOC knows what it can and cannot see.
  • The describes an intrusion as a sequence of stages. Its value is the idea that you do not need to catch the first step; breaking any link stops the attack.
  • The (observe, orient, decide, act) is the tempo of response. Whoever runs the loop faster, attacker or defender, tends to win, which is why speed and good context matter so much.

One more idea runs through this whole course. The old picture of a SOC is analysts clicking through consoles all day. The modern picture is a detection-as-code SOC: detection rules are written as code, reviewed, version-controlled and tested like any software, so a rule has a test that proves it fires on the attack and stays quiet on normal activity. It turns "we think this rule works" into "we proved it does", and it is why this course teaches you to build and test detections, not just click them.

Build it

Produce two things a real SOC runs on: a one-page triage runbook so any analyst handles an alert the same way, and a query that turns the alert log into an honest metric.

  1. Write a triage runbook for one alert type

    Pick impossible-travel sign-in. A runbook says what to check, how to decide, and when to escalate, so a tired analyst at 3 am still does the right thing.

    Markdown
    # Runbook: impossible-travel sign-in
Severity: high | ATT&CK: T1078 Valid Accounts

Context to gather (the SOAR does this automatically):
- the account's last 10 sign-ins: time, city, device, IP
- is there a known VPN or travel for this user?
- what can this account reach (store app, back office, cloud)?

Decide:
- Both sign-ins explained by a known VPN or device  -> false positive, close with note
- One location unknown AND a sensitive action followed -> escalate to Tier 2 as account takeover
- Unsure -> escalate; do not guess

Escalate with: the two sign-ins, what the account can reach, and your one-line reason.

  2. Record every alert in a table you can measure

    The case system is the source of truth. A minimal shape is enough to compute real numbers.

    SQL
    CREATE TABLE alert (
  id        int PRIMARY KEY,
  rule      text NOT NULL,
  severity  text NOT NULL CHECK (severity IN ('critical','high','medium','low')),
  status    text NOT NULL CHECK (status IN ('open','closed')),
  opened_at timestamp NOT NULL,
  closed_at timestamp,                 -- NULL while still open
  analyst   text
);

  3. Turn the log into an honest metric

    Average minutes to close, per severity, over the alerts you actually finished. Read it next to the count, because an average over two alerts says little.

    SQL
    SELECT severity,
       count(*) AS closed_count,
       round(avg(extract(epoch FROM (closed_at - opened_at)) / 60)) AS avg_minutes
FROM alert
WHERE status = 'closed'
GROUP BY severity
ORDER BY avg_minutes DESC;
    Output
     severity | closed_count | avg_minutes
----------+--------------+-------------
 medium   |            2 |         150
 high     |            3 |          90
 critical |            2 |          40
 low      |            2 |          30

    Then always ask the second question the mean hides: which single alert took the longest, and why? That is where the lesson is.

Bring it to your team

Ask these when your team sets up or reviews its detection and response work.

  • For our top alert rules, what share of their alerts are false positives, and who owns tuning the worst one?
  • When an alert comes in at 3 am, is there a runbook, or does each analyst guess?
  • Which decision does each tier own, and does everyone agree on where Tier 1 stops?
  • Are we reading the slowest tenth of our response times, or only the mean?
  • Which log sources are we blind to, and which ATT&CK techniques can we not see at all?
  • Who covers nights and weekends, and how do they reach us when it is real?

Red flags

  • A SOC measured only by how fast it closes alerts, with no check on whether real ones were handled.
  • One rule generating most of the queue, left on for months because "we might miss something".
  • No runbooks, so quality depends on which analyst is on shift.
  • Detection rules that live only in a console, never reviewed, version-controlled or tested.
  • A managed provider forwarding raw alerts no one has the context to action.

Practice

Measure the alert queue

The table alert(id, rule, severity, status, opened_at, closed_at, analyst) holds one morning's alerts. For every severity, return the severity, a closed_count of its closed alerts, and the avg_minutes to close them (the average of closed_at minus opened_at in minutes, rounded to a whole number). Count only alerts whose status is closed. Order by avg_minutes, highest first.

SQL exerciseRuns in a real PostgreSQL inside your browser
-- Average minutes to close per severity, highest average first
SELECT severity, status
FROM alert;
Ctrl + Enter runs
Show a solution
SQL
SELECT severity,
       count(*) AS closed_count,
       round(avg(extract(epoch FROM (closed_at - opened_at)) / 60)) AS avg_minutes
FROM alert
WHERE status = 'closed'
GROUP BY severity
ORDER BY avg_minutes DESC;

The WHERE drops the two open alerts (ids 10 and 11), which have no closed_at and would poison the average. extract(epoch FROM (closed_at - opened_at)) gives the gap in seconds, so dividing by 60 gives minutes, and round makes it a whole number. Reading avg_minutes next to closed_count is the point: medium is slowest here, but it is only two alerts, so one slow alert moved the whole number.

Pass the exercise to finish this task.

Give three alerts a Tier 1 verdict

You are the Tier 1 analyst on Mangrove's morning shift. For each alert below, write a one-line verdict (false positive, needs a look, or likely real) and say whether you close it or escalate, with a one-sentence reason. (1) A store manager's account signed in from the usual city on their usual device, then exported the full customer list, which they have never done before. (2) An EDR alert that a till in one store tried to run a script from a temporary folder. (3) A rule fired because the nightly backup service read a large number of records, as it does every night at the same time.

  • Each verdict is one of the three allowed values and names close or escalate
  • You escalate the customer-list export even though the sign-in looks normal, because the action is the unusual part
  • You escalate the till script, because a POS till should never run scripts
  • You close the backup alert as a false positive and note it for tuning, rather than leaving it to fire every night
Show a model answer

(1) Needs a look, escalate. The sign-in is normal, but a manager exporting the entire customer list for the first time is exactly the kind of action that matters; triage checks the login, but deciding whether this is misuse or a compromised-but-trusted account is Tier 2's call. This is why you watch actions, not just logins.

(2) Likely real, escalate. Tills run a fixed set of software and should never execute scripts from a temp folder; that pattern maps to an attacker running code on an endpoint, so it goes to Tier 2 to scope which till and what ran.

(3) False positive, close with a note and flag for tuning. It is the same known backup service, at the same time, doing its normal job. Closing it is right, but leaving the rule to fire every night is not: note it so Tier 3 narrows the rule to exclude the known service while still catching an unusual bulk read.

Check yourself

A SOC's dashboard shows mean time to respond at a healthy 12 minutes, yet an attacker lived in the network for three weeks before being caught. How do both numbers fit together?

Mangrove's lead wants to cut the false-positive rate, which is crushing the two Tier 1 analysts. A vendor suggests simply loosening the noisiest rules so they fire far less often. What is the risk of taking that advice as given?

A fast-growing company cannot hire enough people for round-the-clock coverage but wants attacks investigated and contained outside office hours, not just forwarded to them. Which option fits best?

Flashcards

Open my review

Key takeaways

  • A SOC runs a loop: detect, triage, investigate, respond and improve. The improve step is what stops it drowning in the same false alarms.
  • Work is sorted by tiers, and each tier owns a decision: worth a look, real incident, act now. Most alerts never leave Tier 1.
  • Learn what each tool is for: the SIEM gathers and correlates, the EDR watches endpoints, the SOAR automates, the case system remembers, threat intel points you at what matters.
  • Every SOC measure can mislead; averages hide the worst cases and any target can be met the wrong way. The real goal is catching and containing real attacks.
  • In-house, MSSP and MDR trade control against cost and coverage. ATT&CK, the kill chain and the OODA loop give the work a shared language, and modern SOCs treat detections as tested code.

Sources and further reading

Episode transcriptA shift on the security desk · about 10 minutes · tap any line to play from there
  1. NadiaImran, picture the security desk of a big building at night. A wall of camera screens, one tired guard.
  2. ImranNobody can watch forty screens at once.
  3. NadiaRight. So motion sensors raise a little light when something moves. The guard only checks the lights.
  4. ImranAnd most lights are a cat on the loading dock.
  5. NadiaMost are. A few are someone trying a locked door. Today we spend a shift at a desk exactly like that, but for a company's computers. It is called a security operations centre. A SOC.
  6. NadiaThe camera feeds are logs. From the app, from laptops, from the network, from the cloud. The motion sensors are detection rules. When a rule matches, it raises an alert.
  7. ImranSo the alert is the little light. Someone still has to go and look.
  8. NadiaYes. And that looking is a loop with five steps. Detect, triage, investigate, respond, and then improve.
  9. ImranWalk me through those. Detect is the rule firing.
  10. NadiaDetect is collecting the logs and turning suspicious activity into an alert. Triage is the quick look. Harmless, needs more work, or raise it. Most alerts get closed right there.
  11. NadiaInvestigate is for the ones that survive. What really happened, and how far did it spread. Respond is containing a real incident and recovering, writing down every step.
  12. ImranAnd improve?
  13. NadiaImprove is the step that saves the team. Every closed alert, you ask, should this have fired at all, and what did we miss. You feed that back into better rules.
  14. ImranBecause without it you answer the same false alarms forever.
  15. NadiaForever, and you still miss the real one.
  16. NadiaIf you can see your screen, the first diagram is this pipeline top to bottom. Four log sources, into a SIEM, into an alert queue, into analysts, then respond. And a dashed line loops back to tune the rules.
  17. ImranYou said SIEM. What is that one?
  18. NadiaA SIEM is a security information and event management system. Think of it as the log warehouse and the rule engine in one. It gathers logs from everywhere and raises alerts when a rule matches.
  19. ImranOkay. And who looks at the queue? Is it one kind of person?
  20. NadiaNo, it is tiers. And the trick is, each tier owns one decision. Tier one triage asks, is this worth a closer look. That is it. A verdict in minutes.
  21. NadiaTier two investigates. Is this a real incident, and how big. Then incident response decides what we actually do about it right now.
  22. ImranAnd above those?
  23. NadiaTier three. The hunters and the detection engineers. They look for the attacker no rule caught, and they write the rules everyone else runs on. That is the senior, creative end.
  24. ImranThe second diagram shows this. Tier one at the top, most alerts closing off to the side. Then tier two, then incident response at the bottom in the warning colour.
  25. NadiaAnd a dashed arrow from tier three runs all the way back to the top. New rules. The pipeline teaching itself.
  26. ImranLet me try the decision idea. A store manager signs in from two cities an hour apart. I am tier one. What do I do?
  27. NadiaWhat does your gut say?
  28. ImranLock the account right away?
  29. NadiaTempting, but no. That is a decision above tier one. Your job is, is this worth a look. You cannot explain two cities in an hour, so yes, escalate it with the context you gathered. Tier two scopes it.
  30. ImranAnd if I disappear into that one alert for two hours?
  31. NadiaThen the queue is not being triaged. Speed with good judgement, that is tier one.
  32. NadiaLet me make it real. Mangrove's SOC is four people. Two tier one on days, one tier two who also hunts and writes detections, and a lead. A managed provider covers nights and weekends.
  33. ImranAnd they watch what, exactly?
  34. NadiaThe app and its APIs, about one thousand nine hundred and twenty store staff accounts, about four hundred checkout tills, and the cloud account running it all.
  35. ImranGive me a morning queue.
  36. NadiaFour alerts. The nightly backup did a bulk export. The two city sign-in. A till tried to run a script from a temp folder. And fifty failed logins on one partner account, then a success.
  37. ImranThe backup one is a false positive.
  38. NadiaClose it, but note the noisy rule for tuning. The two city turned out to be a VPN, so tier two closed it and tuned the rule. The till script and the partner login were real enough to investigate.
  39. ImranWhat made triage fast?
  40. NadiaThe SOAR. That is the automation layer, security orchestration, automation and response. It had already attached each account's recent logins and devices. So triage took minutes, not hours.
  41. ImranSo the tools. SIEM gathers, SOAR automates. What else should I know by name?
  42. NadiaThe EDR, endpoint detection and response. An agent on laptops and tills that records what runs and can isolate a machine. The case system, which remembers every alert and timeline. And a threat intel feed, the outside view of what to look for.
  43. ImranAnd none of those is the SOC.
  44. NadiaNone of them. They are the instruments. The people and the process are the SOC.
  45. ImranNow, the numbers. How does a SOC know it is doing well?
  46. NadiaA few measures. Mean time to detect. Mean time to respond. Dwell time, which is how long the attacker was inside before you found them. False positive rate. And alerts per analyst.
  47. ImranThose sound clean. Where is the catch?
  48. NadiaEvery one of them can lie. Here is my favourite. A lead reports mean time to respond fell from forty minutes to eight. Should you cheer?
  49. ImranI mean, eight is better than forty.
  50. NadiaIt can be. Or they are just closing alerts fast to make the number pretty. And a mean hides its worst cases. Eight minutes could be lots of two minute auto closes and one alert that sat for a day.
  51. ImranAnd the day long one is the one that hurt.
  52. NadiaAlways read the slowest tenth, not just the mean. And watch the false positive rate, because a flood of them burns analysts out, and tired analysts miss the real alert. Burnout is how a SOC quietly breaks.
  53. ImranSpeaking of false positives. A vendor says, just loosen the noisy rules so they fire less. Good idea?
  54. NadiaCareful. Loosen a rule and you may stop it catching the real thing too. That is a blind spot. The fix is to narrow it around the known good cause, like a named backup service, not to weaken what it detects.
  55. ImranOkay, if I wanted to actually do something after this episode?
  56. NadiaTwo things. Write a one page triage runbook for a single alert type, so a tired analyst at three in the morning still does the right thing. What to check, how to decide, when to escalate.
  57. NadiaThen record every alert in a simple table. Rule, severity, status, opened at, closed at. And run one honest query. Average minutes to close, per severity, next to the count.
  58. ImranWhy next to the count?
  59. NadiaBecause an average over two alerts says almost nothing. Then ask the second question. Which single alert took longest, and why. That is where the lesson hides.
  60. ImranWhat do I take to my team, then?
  61. NadiaThree questions. For our top rules, what share of alerts are false positives, and who owns tuning the worst one. At three in the morning, is there a runbook or do we guess.
  62. NadiaAnd, are we reading the slowest tenth of our response times, or only the mean.
  63. NadiaHere is one to try yourself. A dashboard shows a healthy twelve minute response time. Yet an attacker lived in the network for three weeks. How do both fit? Take a second.
  64. ImranResponse only starts once an alert fires. The three weeks is dwell time, before anything fired at all.
  65. NadiaExactly. Fast to what you saw, blind for three weeks. That is why you measure both.
  66. ImranLet me sum up. One, a SOC runs a loop, detect, triage, investigate, respond, improve, and improve is what stops you drowning.
  67. ImranTwo, tiers, and each owns a decision. Worth a look, real incident, act now. Three, learn the tools by their job, and never trust a single number on its own.
  68. NadiaI would add one thing. The modern SOC treats detection rules as code. Reviewed, version controlled, and tested, so you can prove a rule fires on the attack and stays quiet otherwise.
  69. ImranWhich is where this course is going.
  70. NadiaNext time. The logs that matter, and how to query them fast.
Finished reading?Mark it complete to fill in its stop on your course line.

Use it at work

Log triage

Parse auth log lines, group failures by account and address, and flag brute force and spraying.

Open in the Security Lab
Next stopLogs that matter
Was this lesson helpful?
Questions and discussion

Loading the discussion…