Security analyst (SOC) — tasks, one by one
The unit of analysis is the task, not the job title. Each one below carries its direction, whether the judgement rests on evidence or on platform inference, the reasoning, and what it does not establish.
Every task on this page#
Working the alert queue
Automating✓ Evidence-backedGoing through hundreds of alerts a shift and deciding which two are worth looking at.
This is the same task as a guard watching camera feeds and it fails for the same reason: sustained vigilance collapses in about twenty minutes and the base rate of true positives is brutal, so the human baseline is poor and software does not get bored. Correlation and enrichment are also machine-checkable in a way the rest of this job is not — the alert either matches a known pattern or it does not.
The alert queue is where this occupation hires, so automating it removes the training ground rather than the work — the judgement needed further up is currently built by grinding through the queue, and nobody has said what replaces that. Automating triage also does not reduce alerts; it moves the analyst from reading them to tuning what generates them, which is a different and less staffed job.
Deciding it is an incident
Still human-led≈ Platform inferenceCalling it: waking people up, pulling a system off the network, telling the business it has a problem — on incomplete information and before you can be sure.
The cost of the two errors is wildly asymmetric and both are expensive: pulling a production system on a false positive and missing a real intrusion are both career events, and the decision is made with authority rather than certainty. No system is given that authority anywhere we can verify, and the reason is accountability rather than accuracy.
The decision staying with a person does not mean the person is in your building: this is the task most commonly outsourced to a managed service, which moves it without automating it. Read the direction as being about what kind of thing it is, not as a guarantee that your employer will keep employing someone to do it.
Writing the detection
Being augmented≈ Platform inferenceTurning what you learned from one incident into a rule that catches the next one without drowning the queue.
Writing the query is now cheap and models do it well, because a detection rule is code with a testable output. Deciding what to detect is not: it requires knowing what normal looks like in this specific estate, which is knowledge held by people and written down almost nowhere.
Cheap rule-writing makes the false-positive problem worse rather than better, because the constraint was never the writing. A team that can now produce ten times the detections has to be ten times more disciplined about retiring them, and nobody staffs for that — which is how a tool that helps an individual degrades the queue everyone works.
Looking for what nothing alerted on
Still human-led✓ Evidence-backedStarting from a hypothesis rather than an alert — assuming something is already inside and going to look for it.
Hunting is defined by the absence of a trigger, which removes the input every detection tool needs. What replaces the trigger is a guess about an adversary's goal in this particular organisation, and that guess is made from knowing what the company has that is worth taking.
This is the first activity cut when the queue is loud, because it produces no ticket and no metric. A task can be entirely human and still disappear from a team's week without anybody deciding to remove it — and in this occupation that is the usual way it goes.