What Is a SOC (Security Operations Center)?

rundll32.exe C:\Windows\System32\comsvcs.dll MiniDump 720 lsass.dmp full fires a rule at 02:14. Everything that happens between that timestamp and the ticket closing is the SOC.

A security operations center is not the room with the video wall. It is the set of functions that carry an alert from telemetry to a decision, staffed on a rota so someone is doing it while everyone else is asleep. Some SOCs are a room. Some are four people across three time zones in a Slack channel. The org chart matters much less than whether every step in the path below has an owner and a defined next step.

The path of one alert

Telemetry lands

Nothing is detectable that is not collected. Windows Security event 4688 carries NewProcessName, ParentProcessName and CommandLine, but CommandLine arrived only in event version 1 (Windows 8.1 and Server 2012 R2) and stays empty unless the "Include command line in process creation events" policy is enabled. Sysmon Event ID 1 populates it without that policy, which is why most detection content assumes Sysmon or an EDR process table.

This is the step teams skip. A SOC with a good escalation matrix and no CommandLine field is blind to most of the content it has deployed.

The rule fires

title: LSASS Process Dump Via comsvcs.dll MiniDump
id: 4a6b1f70-2c88-4d33-9a41-0f7c9d2b8e15
status: experimental
description: Detects the comsvcs.dll MiniDump export invoked through rundll32 to dump process memory, a common LOLBin route to LSASS credential material.
references:
    - https://attack.mitre.org/techniques/T1003/001/
author: huntrule.com
date: 2026-07-31
tags:
    - attack.credential-access
    - attack.t1003.001
logsource:
    category: process_creation
    product: windows
detection:
    selection_cli:
        CommandLine|contains|all:
            - 'comsvcs'
            - 'MiniDump'
    condition: selection_cli
falsepositives:
    - Crash dump and diagnostic tooling that wraps the same export
level: high

What it catches: the LOLBin invocation, including when rundll32 is renamed, because the match is on the command line rather than on Image. What it misses: tooling that calls MiniDumpWriteDump directly from its own process, handle duplication against lsass with no dump call at all, and anything where the command line is not collected. The false positive list is short and real. We have seen it fire on vendor diagnostic collectors, not on ordinary user activity.

We did not scope the rule to lsass.exe, because the target is a PID on the command line and the process name never appears. That is a blind spot worth writing down rather than pretending away.

Triage

Triage answers one question: is this worth an investigation. Not "is this malicious", which usually cannot be answered in four minutes.

DeviceProcessEvents
| where Timestamp between (ago(1h) .. now())
| where ProcessCommandLine has "comsvcs" and ProcessCommandLine has "MiniDump"
| project Timestamp, DeviceName, AccountName, InitiatingProcessFileName,
          InitiatingProcessCommandLine, ProcessCommandLine

The value of that query is InitiatingProcessFileName. A dump launched by a signed vendor agent under SYSTEM on a build server reads differently from one launched by cmd.exe under a helpdesk account on a finance laptop. The parent is the fastest disambiguator available, and a triage step that does not surface it forces every alert into a full investigation.

Investigation

Investigation widens from the alerting host to the account and the neighbours. For credential access, the question is what the credentials were used for afterwards.

DeviceLogonEvents
| where Timestamp between (ago(24h) .. now())
| where AccountName == "svc_backup"
| summarize logons = count(), hosts = dcount(DeviceName) by LogonType, RemoteIP
| order by logons desc

A service account that normally touches four hosts touching forty is the shape of T1021.002, SMB/Windows Admin Shares, following T1078, Valid Accounts. Triage looks at the alert. Investigation looks at everything the alert implies, which is why they are separate steps.

Containment

Containment is a decision with a cost, so it needs a named owner and a pre-agreed threshold. In practice the ladder is short: isolate the host at the EDR, disable or force a password reset on the account, block the hash or domain at the perimeter, then take the host for imaging. Isolating a domain controller and isolating a laptop are not the same decision and should not sit behind the same approval.

The ordering matters more than the tooling. Disabling the account before isolating the host lets an active operator notice and pivot. Isolating first buys a few minutes of quiet.

Closure

The step everyone under-resources. A closed ticket should record a structured disposition, not free text: true positive, benign true positive, false positive from rule logic, duplicate, insufficient data. Those five values are the SOC's only structured output. Everything downstream, including whether the rule survives, runs off them.

The tiering argument

The classic model splits the path above across three tiers. Tier 1 triages the queue and escalates. Tier 2 investigates. Tier 3 handles the hard cases, threat hunting and forensics. It is the structure most SOC job ladders are still written against, and it scales headcount cleanly.

Many teams flattened it. The usual argument for flattening is retention, and that argument is real: tier 1 is a queue job with no career surface, and people leave it, taking the environmental knowledge with them. The stronger argument is diagnostic. Tier 1 exists in large part to be a human filter for detection content that is not good enough to page anyone directly. When a rule produces four hundred alerts a week and 396 are benign, tier 1 is the mechanism absorbing that. The tier is not a design. It is a symptom being staffed.

The flat model puts one analyst on an alert from open to close, with escalation by topic rather than by rank. It only works if volume is low enough that one person can carry the full depth, which is a detection problem, not an org problem. A team that flattens without fixing its rules just moves the pain onto fewer people.

Tiering is not always wrong. At high volume with genuinely repetitive alert classes and a good runbook library, a split queue is efficient. The question is whether tier 1 is executing runbooks or compensating for rules nobody owns.

Operating models

Every model trades the same currency: who holds the context. A pure MSSP arrangement is cheapest and knows your environment least, which shows up as generic tuning requests that never land. Follow-the-sun is healthiest for the people in it and pushes all its risk into the handover. Hybrid is the most common answer we see, and what decides whether it works is whether the in-house side can change the provider's detection logic or only complain about it.

Metrics, and how each one gets gamed

Every metric below is in real use. Each one has a known gaming mechanism, and naming it is more useful than banning the metric.

• MTTD, mean time to detect. Gamed by starting the clock at alert creation instead of at the earliest adversary action you can evidence. Measured that way it reports queue latency and calls it detection speed. The honest version can only be computed after an investigation reconstructs the timeline, which makes it a lagging metric on a small sample.

• MTTA, mean time to acknowledge. Gamed by opening the ticket and doing nothing. Auto-assignment rules can drive it to near zero without a human reading anything.

• MTTR, mean time to respond. Gamed by early closure. Close at the first plausible benign explanation, and if the activity returns it returns as a new ticket with a fresh clock.

• Alerts handled per analyst per shift. Gamed by bulk close. The highest number on the board belongs to whoever reads the least.

• True positive rate. Gamed by disposition drift in both directions. Push ambiguous cases into benign and the rules look clean. Count policy violations as true positives and they look effective.

• Escalation rate between tiers. Gamed in whichever direction management is leaning that quarter, because the analyst deciding is the analyst being measured.

Four that resist gaming, because they measure whether the machine is assembled rather than how fast it spins:

• Percentage of alert types with a written runbook.

• Percentage of closures carrying a structured disposition rather than free text.

• Median days from the first "false positive from rule logic" disposition to a change on that rule.

• Detection coverage counted as validated techniques, not as deployed rule count.

The third one is the metric almost nobody tracks, and it is the one that predicts the failure below.

The detection engineering relationship

A SOC is the consumer of detection content and the only honest source of feedback on it. Nothing else sees a rule's real-world precision, because nothing else dispositions its output. That makes the link between the queue and the rule owner load-bearing.

When it breaks, the failure is predictable and it is not laziness. An analyst facing a rule that has been wrong ninety-nine times has two options: escalate a hundredth time into a process that will not change the rule, or close it as noise and clear the queue. Under throughput pressure the second is rational. The rule stays deployed, the heatmap stays green, and the technique is undetected in practice while still counted as covered. That gap is invisible from a dashboard.

Three things close it. A disposition value that routes automatically to the named rule owner rather than into a monthly report. A stated turnaround on rule changes, so escalating feels like it does something. And the analyst's proposed exclusion carried on the ticket, because the person who just read forty instances of an alert knows the correct scope better than whoever wrote the rule six months ago. That scoped fix is a host and parent process exclusion, not a global exclusion on the binary, which is the shortcut that quietly disables the rule everywhere. More on that loop in /blog/what-is-detection-engineering.

Summary

A SOC is the path an alert takes, not the place it takes it in: collection, detection, triage, investigation, containment, and a closure record that means something. Tier 1 is often a human filter compensating for rules nobody owns, so treat the tiering question as a detection question first. Every operating model trades the same currency, which is who holds environmental context. Most SOC metrics have a known gaming mechanism, and the ones worth watching measure whether the feedback loop is wired up rather than how fast the queue drains. We have no public benchmark for the rule-fix turnaround number, so the four-day target below is ours and not an industry figure.

collect:
  - windows_security_4688   # requires command line auditing policy
  - windows_security_4624   # logon, pivot on LogonType and RemoteIP
  - sysmon_eid_1            # process creation with CommandLine
  - sysmon_eid_10           # process access, GrantedAccess against lsass.exe
techniques:
  - T1003.001  # OS Credential Dumping: LSASS Memory
  - T1021.002  # Remote Services: SMB/Windows Admin Shares
  - T1078      # Valid Accounts
dispositions:
  - true_positive
  - benign_true_positive
  - false_positive_rule_logic   # routes to rule owner
  - duplicate
  - insufficient_data           # routes to telemetry owner
rule_fix_sla_days: 4

Start from what your queue already complains about. Pull the Windows process creation content at /rules?domain=windows, or the set most likely to be paging someone at 02:00 with /rules?severity=critical.