The job posting says you will monitor and respond to security events. What it leaves out is the ratio. On the SOC desks I have sat on, most of the alerts that landed in a shift turned out to be nothing, and the whole skill of tier 1 is deciding that quickly and writing it down, so the one alert that is something gets your attention while it still matters. Here is one shift, on the same clock as the help desk version of this post.
6:00, the handover
A SOC runs in shifts, so your day starts with someone else’s night. The outgoing analyst leaves a handover note: what is still open, what they suppressed and why, whether the vulnerability scanner is running again this week. Read the whole note. The worst twenty minutes I have had on a desk came from skimming one and re-investigating an alert the night shift had already closed.
Then you open the queue and count. Forty alerts overnight was normal on the desks I sat on. Four hundred means a rule broke or something is actually happening, and you want to know which before you touch anything.
7:30, the alert wave
People arrive at work and sign in, and the detection rules light up. A sign-in from a new device. A sign-in from a country the user was in yesterday, on a laptop that has since flown home with them. A script on a finance machine that turns out to be the inventory job that runs every Monday.
This is where the ratio shows itself. On a quiet morning I would close nineteen of twenty alerts in this hour as false positive or benign true positive, and the difference between those two codes matters more than it looks. A false positive means the rule fired on nothing. A benign true positive means the rule fired on exactly what it was written to catch, and the thing it caught was allowed: an admin running the tool the rule watches for, with a change ticket. Both close the alert. The detection engineer reads them differently: a month of false positives means the rule needs rewriting, a month of benign true positives means it needs an exception.
Each close gets a note, and the note is the actual work product. Who, which host, what you checked, what you saw, why you are closing it. Two sentences for a benign sign-in. Two paragraphs for anything you pulled a process tree for. Six months from now, when that user’s account really is compromised, the analyst on shift will read your notes to learn what normal looked like, and you will be asleep.
10:15, the one that is real
Something in the wave refuses to close. A sign-in flagged for impossible travel, which you have closed thirty times this month because the VPN exit nodes hop countries. This one has a device the user has never signed in from, and ten minutes after it, a new inbox rule that moves anything from their bank into a folder nobody opens.
Now the tempo changes. You pull the sign-in history for the account, run the IP through threat intel, look at what the session did once it was in, and you message the user, because the fastest confirmation available is a person saying “that was not me.” While you wait, you contain what your level allows: revoke the sessions, reset the password, delete the inbox rule, and pull a message trace to see whether anything left that mailbox during the window.
Then you decide whether this is still yours. On most desks the line runs about like this: one account, contained, no sign of movement to a second host, you own it. Anything touching another machine or an admin account goes to tier 2 with your notes attached.
1:00, the quiet stretch
Lunch slows the sign-in rules, and the afternoon is for tuning. That script on the finance machine has fired every week for a month, so you write up a suppression request with the hash and the host. You go back through the morning’s benign closes and check that a stranger could follow each note.
It is also when the phishing reports arrive. Most are marketing mail. One in a stack is a credential page behind a lookalike domain, and that one gets the full treatment: headers, the authentication results, the full recipient list, a purge from each mailbox, and a check of who clicked.
And you study, in the gaps. The analysts who moved up from the desks I was on spent the slow hour reading the detection rule they had just closed an alert on, until they could have written it themselves.
5:45, the end-of-shift note
Fifteen minutes before handover, you write the note you wished you had been given at 6:00. What is open and who has it. What you escalated, with the case number. What you suppressed and until when. Which alert fired forty times today for a reason you understand, so the night analyst can close it in one line instead of pulling a process tree at 2 a.m.
Then you hand it over. The queue refills overnight because the rules keep running, and you leave it in a state the next person can trust.
What the noise is doing for you
Every benign alert you close properly adds one more picture of what normal looks like on that network, and the analyst who can say that is weird in under a minute got there by closing a few thousand alerts that were fine. People who arrive in the SOC from a help desk tend to have a head start here, because they already know what users do on an ordinary day, which is the baseline every detection is measured against.
If you want to feel the rhythm before someone pays you for it, the ServiceDesk Simulator now has a second desk, the Security Simulator, in beta: a queue of alerts and escalated tickets, the consoles a tier 1 analyst works in, and eight close codes with a note on every case. The desk tells you afterwards what actually happened, which on a real desk you learn weeks later, if at all. The beta has a waitlist while it is still behind a passcode.