Working a Shift
Queues, SLA clocks, and a handoff at the end. How a real eight hours in the SOC actually runs.
What you will learn
- -Structure a shift around the queue and the SLA clock
- -Prioritize alerts by severity so the important ones do not age out
- -Manage alert fatigue so you are still sharp at hour seven
You badge in, pull up the dashboard, and the first thing you check is not the newest . It is the oldest unresolved one, because that is the alert closest to breaching its and getting your team a red mark. A shift is a clock-management job as much as a security job, and the analysts who thrive treat it that way.
The rhythm is a loop. Take the next alert, it, close it or escalate it, the outcome, repeat. Do that a few hundred times and the shift is over. The trick is doing it without the queue winning and without your brain turning to mush by hour six.
The SLA clock is always running
An SLA is the promise your made about how fast alerts handled, and it is usually tied to severity. A common breakdown looks like this.
Critical alerts get a response inside 15 minutes, because a confirmed detonation cannot sit for an hour. High severity gets maybe 30 to 60 minutes. Medium gets a few hours. Low might get a full shift or roll to the next day. Those exact numbers vary by shop, but the shape holds: the worse it could be, the faster you must touch it.
This is why you never just work top to bottom by timestamp. A critical alert that landed two minutes ago jumps ahead of a low that has been sitting for an hour. Sort by severity first, then by age within each band. Let a critical breach its SLA because you were clearing lows and that is the review nobody wants to be in.
$index=notable status=new | sort -severity, _time$index=notable status=new | stats count by severity$index=notable earliest=-15m severity=criticalWork the queue without drowning
Some shifts the queue floods: a noisy new detection, a mass phishing wave, a scanner hammering the perimeter. When that happens, do not panic-click. Look for the pattern. Fifty alerts that are all the same phishing sender are one investigation and a bulk close, not fifty separate ones. Grouping related alerts is how you clear volume without cutting corners.
If the flood is a broken or too-sensitive detection dumping garbage, flag it for instead of hand-closing the same all night. A rule that fires 200 times a shift with zero is not helping anyone. It is training the whole team to ignore that alert, which is exactly how a real one slips past.
Alert fatigue is a real threat
Staring at a queue of mostly-noise for eight hours dulls you, and a dull analyst misses the one that counts. This is not a character flaw, it is how attention works, and good analysts manage it on purpose.
Take real breaks away from the screen. Rotate between triage and a deeper task if your SOC allows it, because variety keeps you sharp. And be honest with yourself near the end of a long shift: if you are rubber-stamping alerts closed without really reading them, slow down or flag it. The cost of one missed critical dwarfs the cost of admitting you are fried.
Under queue pressure it is tempting to mass-close alerts as false positive to make the number go down. Only close what you genuinely triaged, and only take actions on systems you are authorized to touch. A queue cleared by rubber-stamping is worse than a full queue, because now the miss is hidden and someone trusts the number.
Your queue has a low-severity alert that has been open for 55 minutes and a critical alert that arrived 3 minutes ago. Which do you work first, and why?