The Security Operations Center: who watches, and how

Every organisation that takes security seriously eventually needs someone whose job is to watch. Firewalls block, antivirus scans and backups save you after the fact, but none of them notices that something unusual is happening across the whole organisation. That is the job of a Security Operations Center, usually shortened to SOC. NIST describes a SOC as a centralised function that monitors, detects and responds to security events and incidents, typically around the clock.

A SOC is not necessarily a room full of screens. In a large bank it may be exactly that, with dozens of analysts on shifts. In a university or a charity it may be three people and an outsourced partner who covers nights and weekends. What makes it a SOC is the function: a clear owner for “is something wrong right now, and what do we do about it?”

What a SOC actually does

• Collects signals: logs from servers, laptops, cloud services, firewalls and identity systems.
• Detects: turns those signals into alerts using rules, correlation and, increasingly, machine learning.
• Triages: decides quickly which alerts are real, which are noise, and which are urgent.
• Responds: contains an incident, or hands it to an incident response team with the evidence already gathered.
• Improves: tunes detections, writes playbooks and feeds lessons back to the people who build and run systems.

The tier model

Most SOCs organise analysts in tiers, so that the flood of alerts is filtered by people with increasing experience. The names vary from one organisation to another, but the idea is widely shared:

Around this core sit supporting roles: detection engineers who write and tune rules, threat intelligence analysts who track what attackers are doing, and platform engineers who keep the logging pipeline running. In small teams one person may wear several of these hats.

A day in the queue

A typical shift starts with a handover: what happened overnight, which incidents are open, what the previous shift was watching. Then comes the queue. An alert might say that an account logged in from two countries within an hour, that a laptop contacted an address on a threat list, or that a server started sending far more data than usual. For each one the analyst asks the same questions: Is it real? What else happened on that machine or account around the same time? Who needs to know, and how fast?

Good analysts write down what they checked and why they closed an alert, even when it was harmless. That record is what makes the next investigation faster, and it is what an auditor or a court will want to see if an incident turns serious.

The enemy inside the SOC: alert fatigue

The biggest risk to a SOC is not a clever attacker, it is noise. When hundreds of low-value alerts arrive every hour, people start closing them without reading, and the one real alert slips through. Mature SOCs fight this deliberately: they measure how many alerts turn out to be real, remove or rewrite rules that are almost always wrong, and add context automatically so an analyst does not start every investigation from zero.

Metrics that matter

• Time to detect: how long between the start of an attack and the first alert.
• Time to respond: how long between the alert and containment.
• True-positive rate: what share of alerts were real, per detection rule.
• Coverage: which attacker techniques (for example, those listed in MITRE ATT&CK) you can actually detect, and which you cannot.

Counting alerts closed per hour is a tempting metric and a poor one: it rewards speed over care. The goal is fewer, better alerts and faster, correct decisions.

SOC skills on your own Mac

You do not need a SOC to think like one. The core habit is the same: know what normal looks like, notice what is new, and ask why. On a Mac, FireAI’s Activity view shows which apps connect where, newest first, and the Threats page lists the connections it flagged with the reason in plain words, so you can investigate before you decide. That is triage on a scale of one.