Case file · anonymized · MSSP · SOC · detection engineering

The MSSP added a step. They didn't remove one.

A MITRE T1114.002 alert about an authorized monitoring tool, no analyst outreach, ten-minute CIO-to-CISO triage — and what competent SOC triage actually looks like.

2026-07-08 · 6 min read · worked by the principal

Yesterday a customer's MSSP filed a MITRE T1114.002 alert.

About my own authorized monitoring tool.

Reading the customer's email metadata. Exactly as the customer asked us to.

They CC'd me on the alert. About myself.

What actually happened

The customer engaged us to run a focused mailbox-rule review across their tenant — the same engagement that's surfaced 706 attacks in another tenant and seven roles on a forgotten admin in a third. The CISO scoped it, signed it, and added us to the engagement list inside the customer's own ticketing system three weeks ago.

Our read operations hit the customer's Microsoft 365 tenant. Standard Graph API calls, against a registered app with documented consent, originating from an IP in our published operator range.

The MSSP's detection rule fired on the Graph audit log: MailboxLogin events from a non-user identity reading a privileged user's mailbox metadata. Mapped to MITRE ATT&CK T1114.002 — Remote Email Collection. Severity: high.

The MSSP analyst filed the ticket and waited.

Nobody at the MSSP reached out to ask whether the activity was authorized. Nobody checked the customer's running engagement list. Nobody pinged the CISO. They just filed the ticket.

How it got triaged

The customer's CIO triaged it by texting me directly:

"Is this you?" "Yes." "OK, closing it. Thanks."

Total elapsed: less than ten minutes.

She replied to the MSSP analyst: "Intentional — initiated by our CISO. You can close the ticket."

The MSSP added a step. They didn't remove one.

Why this happens

I've worked with enough MSSPs to know this isn't a one-off. The structural cause is consistent across every shop that pulls this pattern.

The L1 SOC analyst working your ticket is offshore, working 8-12 alerts per hour, on a queue.

They've never met your CISO. They don't know what your business does. They don't have the customer's engagement-tracking system open in another tab. They don't have a phone number to call, and even if they did, the ticket SLA penalizes them for spending time on outreach instead of dispositioning.

Their compensation structure rewards alerts closed per hour. Their performance dashboard counts open tickets as inventory. The fastest path through their queue is the one that doesn't require talking to a human.

So they file the ticket. They tag it "awaiting customer confirmation." They move on. The customer absorbs the friction of triaging the SOC's own alert.

That's not a defect of any one analyst. That's the operating model.

The actual cost

Two costs accumulate.

Alert fatigue at the customer's leadership level. The CISO opens her inbox and sees three of these per week. After enough cycles, she stops reading carefully. The high-confidence finding that actually matters arrives next month and gets the same triage attention as the false positives — which is to say, not enough.

Real signal gets buried. During the same week that the MSSP filed the alert on our authorized activity, they also missed a real adversary-in-the-middle session-cookie replay on a CFO account at the same customer. The cookie was used from an IP one /24 away from the operator's normal location. The MSSP's rule fired. The L1 analyst dispositioned it as "low-confidence travel anomaly" and closed it. The actual compromise sat for nine days before the customer's CFO noticed mail going to a folder she didn't recognize.

Both alerts came from the same SOC, the same week. One was a beacon for paid attention. One was a forwarder for the customer's own work. The SOC handled both the same way.

What good triage looks like

This isn't a counsel-of-perfection. It's what we do every time a high-severity finding lands at our shop, and it costs us about five minutes per alert.

1. Check the customer's engagement list first. Every operator authorized to act in the tenant is named in writing. Cross-reference the alert's actor against the list before doing anything else. If the actor is on the list, the disposition is one paragraph: "Authorized engagement, [name], [scope]. Closing."

2. Identify the real human and the real phone number. Every customer relationship has one named CISO contact and one backup. Both their cell phones are in the SOC runbook. If the engagement-list check is inconclusive, the next move is a 30-second call to the CISO before the ticket is filed.

3. Time-box the triage at 5 minutes. If you can't disposition the alert with confidence in 5 minutes — escalate. Don't park it in "awaiting customer confirmation" and move on. Escalation is the signal that the rule needs tuning.

4. Build the false-positive into the rule. Every authorized operator's IP range, every named tool, every documented scope — encoded as exclusions or context fields in the SIEM. The customer's authorized activity should NOT generate ticket noise. Every alert that fires should require a human's judgment.

5. Measure SOC time spent reading the customer's runbook. If the SOC's KPI is alerts closed per hour and never weighted by how many of those closures were "ask the customer," the incentive is to never ask. Fix the measurement.

A SOC that does these five things will have one tenth the false-positive volume of one that doesn't. The customer experience flips from "the SOC is one of my burdens" to "the SOC is one of my eyes."

What you should require from your MSSP

Three asks. All reasonable. All free.

• Show me your engagement-list integration. How does the SOC know who's authorized to do what in my tenant? If the answer involves a Word document that nobody updates, you have a problem.
• Show me your last 30 days of alerts dispositioned without customer outreach. Filter for high-severity. Calculate the percentage. If it's >70%, the SOC isn't asking enough.
• Show me the runbook entry for "alert on a named operator." If there isn't one, ask why.

If you're paying for a SOC that can't tell legitimate operations from a beacon — and won't even ASK before billing the alert — what exactly are you paying for?

Anonymized per our marketing policy. The MITRE technique, the alert type, and the ten-minute triage figure are real; the customer, the MSSP, and the date are generalized.

Seeing this pattern in your tenant? The person who worked this case answers the email. Originally published on the Envyously blog.