Detection Architecture: How Burrow Decides What to Alert On

Burrow runs a large set of detection rules, but the harder problem is not detecting activity — Microsoft 365 audit is full of it — it is deciding which activity is worth a human's attention. Burrow's answer is a three-step model that separates "what shape is this activity" from "did the person mean to do it" from "is there anything corroborating it." This article explains that model so you can read the Trigger Why text on an alert and understand why it fired at the severity it did.

Why a model, not a pile of gates

Early on, false-positive suppression was a growing stack of independent fixes — each noisy pattern got its own subtractive gate, and that gate had to be copied into every rule that fired on the same activity. Miss one rule and the same benign activity would escalate into an incident through the arm you forgot to patch. It was a treadmill.

The current design replaces that with three composable steps that each rule shares, so a fix applied once applies everywhere.

Step 1 — A shared activity-shape classifier

There is now one classifier that recognises the benign shapes of activity, and every spike detector calls it instead of carrying its own copy.

The shapes it recognises are the same ones documented in the noise gates catalog — an Office-Online or Office-Desktop document open, a single dominant large file, a folder downloaded as a ZIP, application-data churn, a reorganisation-shaped set of deletions, and so on. Because the classifier is shared, adding a new benign shape once demotes it in every rule that could have fired on it. No more missed-arm escalations.

When you see a demotion in an alert's Trigger Why, this classifier is what produced it, and the noise gates article is the catalog of what it recognises.

Step 2 — Download intent, decided at ingestion

Raw download volume is a poor signal — most high-volume downloads are benign (sync clients, viewer rendering, folder-zip packaging). So every download is tagged with an intent the moment it is ingested:

• Office open — a document opened in Office (Online or Desktop). Not a copy leaving the tenant.
• ZIP pull — the folder-as-ZIP packager fetching files to build a download.
• Sync pull — the OneDrive sync client doing its job.
• Browser pull / API pull — a person or a tool deliberately pulling files.
• Client other / unknown — anything that does not positively match a benign shape.

Rules then key on the deliberate subset — browser, API, and unknown — rather than raw volume. The three positively-benign intents (office open, ZIP pull, sync pull) do not count toward exfiltration thresholds.

A deliberate safety choice: an unknown or stripped user-agent counts as deliberate, not benign. A novel exfiltration tool that hides its identity is therefore never silently demoted — only "downloads present, but zero of them deliberate" demotes. Burrow errs toward surfacing the unknown.

Step 3 — Corroboration

The third step runs after all of a cycle's signals for an entity are assembled. A weak or behavioural signal firing entirely alone — no other independent medium-or-higher signal for that entity, and no intrinsic hard evidence (nothing sensitive, nothing shared externally, no new sign-in country, no deliberate bulk pull) — is held at low. It is still written and still visible in the dashboard, but it sits below the email threshold.

The reasoning: a lone "unusual hour" or "day-of-week drift" with nothing else around it is rarely worth waking someone. The same signal with corroboration — it fired alongside an external share, or a first-ever country, or a real deliberate pull — keeps its severity and emails.

Every weak alert records what it was (or was not) corroborated by, so the decision is auditable in the Trigger Why. This step is demote-only — it can never raise a false alarm, and it never touches the primary threat rules (ransomware, mass deletion, exfiltration, external sharing of labelled content, the authentication rules). Those always fire on their own merits.

How the three steps combine

For a given entity in a given cycle:

1. Shape — is this a recognised benign shape (Office open, single file, folder-zip)? If so, demote.
2. Intent — of the downloads present, how many were deliberate? Thresholds count only those.
3. Corroboration — if what survives is a lone weak signal with no hard evidence beside it, hold it at low.

What clears all three emails at its real severity. What does not stays visible in the dashboard at low severity — removed from your inbox, not from the record.

Where each step surfaces

• The shape demotions are cataloged in noise gates.
• The intent breakdown appears in the investigation digest ("real downloads vs viewer rendering") and in the download-method line of the evidence box.
• The corroboration verdict appears in the alert's Trigger Why text in the evidence box rule-engine card.

A watched user (heightened monitoring) has the corroboration hold bypassed — their lone weak signals surface and email so nothing is missed during the watch.

Turning it off

The corroboration model has a kill switch for operators who want every weak signal to email regardless (rare, and much noisier). Contact support@smikar.com if you have a reason to disable it — it is on by default because it is the single biggest driver of a quiet, high-signal inbox.

See also

• Noise gates — the catalog of shapes step 1 recognises.
• The investigation digest — where download intent is spelled out in plain English.
• How an alert flows through Burrow — the end-to-end pipeline this model sits inside.
• Reading the evidence box — where the Trigger Why text lives.
• The tuning model — the operator controls layered on top of this.

Need help? support@smikar.com.