The Paranoid SOC

An AI SOC arrives knowing every way your company could be attacked and almost nothing about how it normally runs. Show it a service account reading the directory at 2 a.m. and it will name the ATT&CK technique, the groups that use it, and what they usually do next. Ask how the same read could be routine and you get one sentence that would fit any alert ever raised. Left to itself, a SOC like that finds APTs in your inventory job.

That lopsidedness gets in the way of an idea worth taking seriously: treat every alert as a true positive.

That sounds like a SOC drowning in incidents, until you look at what an alert is. A directory-enumeration rule fires because a service account read four thousand computer objects. That happened. The rule saw what it was built to see. When an analyst closes it as a false positive, they almost never mean the rule was wrong. They mean the thing happened and it was fine. Microsoft Sentinel’s close menu is honest about this. It reserves “false positive” for incorrect alert logic or incorrect data, and files the rest under “benign positive,” suspicious but expected.

So drop the false-positive bucket. Every alert is a true positive, and the open question is what it’s a true positive of. The SOC stops handing you verdicts and hands you a board instead, listing the explanations still in play for each alert, attacks and routines side by side, each with rough odds.

This is where the lopsidedness bites. A model fills the attack side of the board in detail and the routine side with a guess, and a board like that tips toward the attack.

That’s the argument of this post. A SOC can treat every alert as a true positive only if it can name the routine behind each one as specifically as it names the attack, and that takes knowing your company far better than security tools do today.

A ladder of knowing

Picture a ladder whose rungs are things the SOC already knows about the company before an alert fires, in roughly the order a new analyst learns them.

The alert comes from The Sycophantic SOC, this post’s mirror image. There, a service account called svc-inventory read four thousand directory objects every Tuesday at 2 a.m., and analysts correctly closed it each week as the asset-inventory job. Eight months in, an attacker who had stolen the account’s credential read the directory with it on a Thursday at 2:04 p.m. Put both alerts, Tuesday’s and Thursday’s, in front of a SOC that treats them as true positives, and climb.

Day one: it knows the event and the internet. The SOC knows that an account enumerated the directory over LDAP, and it knows everything that has been published about attackers. The attack side of the board fills itself in. Domain account discovery is a catalogued technique, T1087.002 in MITRE ATT&CK, a standard early step for anyone mapping a network they’ve broken into. The model can name the tools that do it, the groups that use it, and what usually comes next. The routine side of the board says “possibly legitimate administrative activity,” which predicts nothing.

So the board can’t hold odds. It has one detailed hand and one shrug, and Tuesday looks identical to Thursday. From here a SOC has two ways out. It can weigh the only story it can tell, go looking for the next step in the attacker’s playbook, and find it, because an enterprise network is full of activity that matches some playbook. That’s the paranoid SOC. Or it can decide most things are fine and close both alerts, which is the sycophantic SOC’s mistake made on day one instead of learned over eight months.

Week one: it knows who the account is. The identity inventory says svc-inventory belongs to the IT asset team, runs the asset-management tool, and has read access to the directory. The routine hand now has a name, the tool doing its job. The tool could do its job at any hour from anywhere it’s installed, though, so the hand still predicts very little. Tuesday and Thursday still look the same, and a lookup against the asset database and an owner field is where a lot of alert enrichment stops.

Month three: it knows what the account usually does. Eight months of history show the job runs on Tuesdays at about 2:00 a.m., from one server, INV-01, and reads about four thousand objects. Now the routine hand predicts a day, an hour, a host, and a count. Tuesday matches all of them. Thursday matches none.

Behavioral analytics live at this rung, and it’s a real improvement, but Thursday only gets as far as “unusual.” Inventory jobs get re-run off schedule all the time, after a directory migration or a failed run, or when an auditor asks for a fresh export. A SOC that knows only the baseline can say Thursday is strange but not why. Robin Sommer and Vern Paxson called this the semantic gap in 2010, the missing step between flagging a deviation and handing an operator something they can act on. It’s a large part of how anomaly detection earned its reputation for noise.

Year one: it knows how work gets done here. This rung is what a veteran picks up and no tool records cleanly. Off-schedule inventory runs need a change ticket. The asset team re-runs the job after directory migrations, always from INV-01. A couple of admins test service accounts from their own workstations, which they shouldn’t, and it shows up in the on-call notes when they do. Thursday’s board now holds three routine hands instead of one, and each one names the record that would prove it, whether a change ticket, activity on INV-01, or an admin session with a matching note.

Thursday has none of them. The request came from an admin workstation, there’s no ticket, INV-01 was idle, and nobody on call touched the account. Every routine the company has for this behavior has been checked and failed, and “someone else holds the credential” rises to likely. Tuesday has its proof, because the scheduler on INV-01 logged the job starting at 2:00.

Year five: it knows what’s going on this week. The last rung is situational. There’s no directory migration this month. The red team’s engagement ended in August. The admin whose workstation sent the request is on leave. None of that lives in a security tool. It lives in project plans, calendars, the HR system, and a chat channel. Anyone with access could look those up on day one. What five years buys is knowing which of them bear on a directory read at 2:04 p.m., and where each one is written down. With it, Thursday goes from likely to “page someone now,” and Tuesday stays where it was.

The attack hand was fully written on day one. Every change on the board came from the routine side.

Look at which side of the board moved. The attack hand was complete on day one, and it didn’t change as the SOC learned the company. All the movement came from the routine side, which went from a shrug to several specific explanations, each with a record that could prove it. Richards Heuer described why that matters in the CIA’s Psychology of Intelligence Analysis: “If an item of evidence seems consistent with all the hypotheses, it may have no diagnostic value at all.” On day one, four thousand objects read at 2:04 p.m. fit “attack” and fit “something legitimate,” because “something legitimate” fits anything. Knowing the company is what made the same evidence mean something.

The odds themselves should stay coarse, in bands like likely, possible, remote, and ruled out. A crisp 0.37 would be its own kind of lie. Most of the value is in which hands are alive, which are dead, and which ones nobody can explain.

Proving the routine beats disproving the attack

There are two ways to lower the odds on an attack hand, and they behave very differently.

The first is absence of evidence. You list what the attack would have left behind and look for it: a new process on the source host, a second account touched, data leaving the network. Not finding it lowers the odds a little, and only if a sensor would have seen it. There’s always another trace you didn’t check, and a careful attacker works to leave none. That search has no last rung, which is why I’ve argued that benign has no proof.

The second is a positive explanation. Instead of proving the attack didn’t happen, you show that something else produced the alert. The scheduler on INV-01 started the inventory job at 2:00 a.m., read four thousand objects, and finished. That’s one lookup, and it ends. Benign in general has no proof, but a specific routine does. It has a witness, the same way an attack does.

Ruling an attack out by absence never finishes. Ruling a routine in by its witness takes one lookup, if you know the routine exists.

A witness explains the alert. It doesn’t clear the company. An attacker who controlled INV-01 itself, and waited for Tuesday at 2 a.m., would produce an identical scheduler log. What a specific routine does is shrink the attack hands still standing to the ones that look just like your routine, which is a much smaller set, and one that costs the attacker a lot more knowledge about you.

The catch is that you can only look up the witness for a routine you already know about. The attack side of the board is written by the whole security industry, with every technique catalogued, every group profiled, and every intrusion written up somewhere. The routine side is written by nobody. Your inventory schedule, your VPN’s egress city, the quirk in your remote-management vendor’s updater, and the admin who tests accounts from their laptop aren’t in any training set or threat feed.

That’s why paranoia is the natural failure of an AI SOC that lacks context. Picture an analyst who has read every threat report ever published and has never worked a day at your company. Show them a 2 a.m. directory read and they’ll see reconnaissance, because reconnaissance is the only story they know how to tell about it. Their knowledge of attackers is fine. They just know nothing about you.

It also puts both failures on one line. The paranoid SOC is missing the routine hand, so the attack wins by default. The sycophantic SOC has a routine hand that’s too blurry. It learned “service accounts enumerate the directory here,” wide enough to swallow a Thursday afternoon. One knows too little about the company and the other knows it too vaguely.

What the SOC remembers

Stay with svc-inventory a little longer. Say Thursday’s intrusion gets caught. Responders rotate the credential and close the case with a thorough write-up: how the credential was stolen, the admin workstation the request came from, the directory read, the technique. A SOC with a memory that every investigation writes back to keeps that write-up, as it should.

Three weeks later, at 2:00 a.m. on a Tuesday, the inventory job runs from INV-01 as usual. The alert fires, and the SOC checks its memory for the account. It finds one detailed record, “svc-inventory: compromised, used for domain reconnaissance,” and reads it as a fact about tonight. Then it looks for the attacker’s next step and finds one. In the same hour, a scheduled update installs a new service on INV-01, and installing a service is a catalogued persistence technique, T1543.003 in ATT&CK. Put together, that’s a stolen credential, reconnaissance, and persistence, and the SOC calls it critical.

None of that story is made up. The compromise happened three weeks ago, to a credential that no longer exists. The directory read is the inventory job, and the new service is the patch. Every claim was retrieved from something real, and none of them is about tonight.

The trouble is in what the memory holds about the Tuesdays before this one. Each closed with a single word, “benign.” An investigation that finds an attack leaves a detailed write-up, with a technique, hosts, and a sequence a later investigation can match against. An investigation that finds a routine leaves a label that predicts nothing. So one attack story outweighs eight months of routine, and a SOC whose memory is only its case history gets more paranoid the longer it runs. It climbs the ladder on the side that was already full.

Some extra suspicion after a compromise is fair, and a closer look at the account’s next few runs is good practice. A critical incident on the strength of a closed case is not, when the routine’s record is one lookup away. The fix is in what the memory keeps. It needs routines stated specifically enough to check (“inventory job, INV-01, Tuesdays around 2:00 a.m., about four thousand objects, logged by the scheduler”) and facts tied to the time they were true, so “compromised” carries the date the credential was rotated. With those, this Tuesday comes down to the scheduler log, the patch system’s record of the update, and the rotation date on the old case, and each of those checks ends.

How well you have to know the company

The bar for a SOC that treats every alert as a true positive comes out concrete. For any alert, it has to be able to name the routine that would have produced it and the record that would prove it, as specifically as it can name the attack.

For one service account that took a page of facts: owner, tool, host, schedule, volume, how off-schedule runs happen, who tests the account and where that gets written down, what’s going on this month. A company has a great many accounts like it. Palo Alto Networks’ 2026 survey of 2,930 security decision-makers counted 109 machine identities for every human, and AI agents made up 79 of the 109. Not every one of those runs a job you’d need to explain, but plenty do. Then add the human routines, like who travels where, which vendor patches on which night, where the VPN egresses.

The rungs also live in different places. Who owns an account lives in the directory and the asset database. What it usually does lives in the logs. How work gets done lives in ticket systems, runbooks, and people’s heads. What’s going on this week lives in calendars and chat. Security tools reach the first two well. The last two are tribal knowledge, the part most SOCs never write down, and they’re the rungs where Thursday separated from Tuesday. Pulling all four into one place the SOC reads before it decides is what a context lake is for. Full disclosure: that’s what we build at Simbian.

The knowledge also goes stale. Routines change every week. A migration moves the inventory job to a new server, and a SOC still working from last quarter’s picture will either flag the new server forever or keep trusting an old explanation after an attacker has learned to wear it.

When nobody can name the routine

Sometimes the SOC can’t name one, and what it does next decides which failure you get. The paranoid SOC treats “I can’t explain this” as “this is an attack.” The sycophantic SOC treats it as “this is probably fine.” Both turn a gap in the SOC’s knowledge into a claim about the world.

The honest move is a third state on the board: no known routine explains this. That’s neither an incident nor a close. The SOC turns it into a question for the people who know the company, instead of answering it alone. Does anyone re-run the inventory job by hand? The answer becomes context the next alert gets without asking. A context gap is a ticket for the asset team, not a page for the incident responders.

It has a cousin worth tracking separately. Sometimes the routine is known but its record isn’t kept, because nothing logs the scheduler on INV-01. That one is a telemetry purchase, and a month of them is a list of which logs to turn on first.

Where this breaks

Attackers wear routines on purpose. Living off the land is the practice of making an attack look like the company’s own behavior, and a SOC that learns your routines gives attackers a target to imitate. Specificity is the defense. “A service account reads the directory” is easy to wear. “INV-01, Tuesdays at 2 a.m., about four thousand objects, logged by the scheduler” is much harder, because the attacker has to know all of it and control the right server at the right hour.

Some of the context is attacker-writable. A change ticket’s description, a commit message, or a note saying the run was “approved by IT” are text, and a model that reads meaning can be moved by meaning. A witness should be a record a system wrote, like the scheduler’s log, not a sentence someone typed.

The attack side is only as complete as what’s been documented. Day one’s attack hand was detailed because domain enumeration is well catalogued. A technique nobody has written up yet gets no hand at all, and nothing checks for it.

Paranoia is cheap

A paranoid SOC is easy to build. Assume every alert is real and list the attacks that fit; the security industry has spent decades writing that list for you. What nobody has written is the other list, every ordinary reason your company’s systems do strange things, specific enough to check. That list is the price of treating every alert as a true positive without inventing APTs.

A SOC that knows your company like a five-year veteran can afford to suspect everything, because it can prove the routine and let the rest stand. One that doesn’t will either find APTs in your inventory job or stop looking at it.