Escalation Framework

The ambiguous 30%

About 70% of SOC alerts resolve cleanly at L1. They match a pattern the triage framework covers — known-good source, known FP pattern, clearly malicious indicator. The analyst classifies with confidence and moves on. Another 5-10% are clearly critical — active ransomware, confirmed credential compromise with ongoing exfiltration, security tool tampering. These escalate immediately per severity.

The remaining 20-30% are ambiguous. The alert is suspicious enough that closing it feels wrong, but there's no clear evidence it's malicious. The analyst can't classify. The triage framework doesn't resolve it. This zone — between "obviously benign" and "obviously critical" — is where real attacks hide, because ambiguous alerts are the ones most likely to be closed without investigation in SOCs that lack an escalation framework for ambiguity.

Most escalation frameworks handle the first two categories well. Severity-based routing sends Critical and High alerts to L2 or the SOC lead. Known FP patterns resolve at L1. But the ambiguous category — where the analyst's honest assessment is "I don't know what this is" — has no defined path in most SOCs. The analyst either closes the alert (risky), spends 30 minutes investigating beyond L1 scope (slow), or walks over to the L2 analyst and asks informally (unstructured, undocumented, doesn't work when L2 is remote or on a different shift).

NE's escalation framework addresses this with three structured triggers that specifically handle ambiguity. The framework changed after INC-NE-2026-0342 proved that the inbox rule compromise hid in the ambiguous zone for 4 days before being detected through a separate alert.

Estimated time: 40 minutes.

Trigger 1: Capability — the 15-minute boundary

The capability trigger is the simplest: the L1 analyst has spent 15 minutes and cannot classify the alert. This is the automatic escalation from Section 1.2's tier boundaries. No judgment required — the clock is the trigger.

The capability trigger catches alerts that are genuinely complex. Not every alert resolves in 15 minutes, and that's not a failure of the analyst or the triage framework. It means the alert requires investigation depth — cross-table KQL joins, entity timeline reconstruction, behavioral analysis — that exceeds L1 scope. The escalation is a design feature, not a breakdown.

At NE, approximately 20% of alerts trigger capability escalation. Of those, about 60% result in L2 confirming the alert is benign (but requiring investigation to reach that conclusion), 25% result in confirmed incidents requiring containment, and 15% are reclassified back to L1 because the analyst missed a step in the triage framework. That 15% is a training signal — it tells the SOC lead which parts of the triage framework analysts struggle with, so targeted training can address the gap.

Trigger 2: Pattern — cross-alert correlation

The pattern trigger fires when the L1 analyst notices that the current alert correlates with other alerts on the same entity within a recent time window. A single failed-MFA alert might be benign. Three failed-MFA alerts from different IPs on the same user within 2 hours is a pattern that suggests credential compromise testing.

How to check for patterns

The pattern check is a standard step in the triage framework (Section 1.5), but it becomes an escalation trigger when the pattern exceeds what L1 can resolve. The L1 analyst runs the related-alerts query — checking for other incidents involving the same user, IP, or device in the last 24 hours. If the query returns multiple alerts across different detection rules, the pattern might indicate a multi-phase attack chain. Evaluating whether correlated alerts represent an attack chain requires L2 investigation depth.

The related-alerts check is a quick KQL query that looks for recent incidents involving the same entities. The analyst doesn't need to write the query from scratch — it's a saved query in the Sentinel workspace that takes an entity identifier as input and returns incidents from the last 24-48 hours. The output shows how many other alerts exist, what detection rules produced them, and the time sequence. If the output shows a single isolated alert, the pattern trigger doesn't fire. If it shows multiple alerts across different rule categories (identity + email + endpoint, for example), the pattern trigger fires because cross-category correlation suggests an attack that spans multiple phases.

The time window matters. A credential compromise alert and an inbox rule alert for the same user within 30 minutes is a strong correlation — the sequence matches a known attack chain. The same two alerts 3 days apart might be coincidental. NE uses a 4-hour correlation window for the pattern trigger — tight enough to catch attack chains, loose enough to avoid excessive false pattern matches.

At NE, a typical pattern escalation looks like this: "Pattern trigger. User j.martinez@ne.com has three correlated alerts in the last 4 hours: suspicious sign-in from unusual location (14:22), inbox rule creation (14:47), and MailItemsAccessed spike (15:30). Individual alerts might be benign — user could be traveling and organizing email. But the combination matches a credential compromise → persistence → reconnaissance chain. Requesting L2 investigation to determine whether this is a legitimate user session or multi-phase attack."

The pattern trigger catches what individual alert analysis misses. Each alert in isolation might close as benign. Together they tell a story that only becomes visible when someone checks for correlation. The pattern trigger ensures someone checks. Without it, the three alerts would be triaged independently by whichever analyst happened to pick each one up — potentially by different analysts who never see the connection.

Trigger 3: Instinct — the judgment escalation

The instinct trigger is the most important and the most culturally difficult. It allows the analyst to escalate based on judgment alone: "Something doesn't look right and I can't articulate exactly why."

Why instinct matters

Experienced analysts develop environmental awareness that goes beyond documented rules. They notice things that don't fit patterns they can name — a service account authenticating at an unusual time, a user who never works late suddenly active at midnight, an inbox rule that's technically legitimate but oddly specific. These observations don't match any triage framework criterion. The data doesn't show anything definitively malicious. But the analyst's accumulated experience flags it as wrong.

In SOCs without an instinct trigger, these observations get closed. The analyst can't justify escalation because nothing in the data meets the formal criteria. They close the alert, maybe with a note saying "unusual but no evidence of compromise." The alert is gone. If it was the early stage of an attack, the window to catch it closes with the ticket.

The INC-NE-2026-0342 case

The inbox rule alert that opened this section — the 'Archive-2026' rule created at 06:47 — would have been closed under the pre-incident escalation framework. The triage framework showed nothing malicious: successful MFA, familiar device, legitimate-looking rule name. The only anomaly was the timestamp — 90 minutes before the user's typical start time. That anomaly didn't meet any formal escalation criterion.

After the incident (which was eventually detected four days later through a separate BEC indicator), NE added the instinct trigger. The same alert today would be escalated as: "Instinct trigger. Inbox rule creation for Finance user at 06:47 — 90 minutes before typical start time. Rule moves emails containing 'invoice' and 'payment' to a new folder. Nothing formally malicious but the combination of early-morning timing, Finance user, and payment-keyword rule feels like evidence staging. Requesting L2 check of MailItemsAccessed and sign-in source details."

That escalation would have caught the compromise four days earlier. The L2 investigation would have checked the sign-in source, found it originated from a residential proxy in a different country, and confirmed the account was compromised. The instinct trigger — "the timing feels wrong" — was the only signal the data offered at that point. Every other indicator was clean.

Protecting the instinct trigger

The instinct trigger only works if analysts aren't penalized for using it. If escalation volume is tracked as a negative metric — "you escalated 15 alerts this week, that's too many" — analysts stop escalating uncertain alerts. They close them instead. The instinct trigger dies.

NE's policy is explicit: instinct escalations are never counted against L1 performance metrics. The escalation accuracy metric (tracked in Section 1.6) measures whether capability and pattern escalations were warranted, but instinct escalations are excluded from accuracy calculation. An analyst who uses the instinct trigger ten times in a week and nine are benign is an analyst with good judgment who's being appropriately cautious — not an analyst who's wasting L2 time.

The cultural signal matters more than the policy. When the SOC lead receives an instinct escalation and responds "good catch, let me look at this" — even when it turns out benign — that response reinforces the behavior. When the SOC lead responds "this doesn't look malicious, why did you escalate?" the analyst learns not to escalate next time. The SOC lead's response to instinct escalations sets the culture. The culture determines whether novel attacks get caught.

The structured escalation format

Every escalation — regardless of trigger type — uses the same four-field format. The format ensures L2 receives enough context to continue rather than re-triage.

Field 1: Trigger type. Capability, Pattern, or Instinct. This tells L2 why the alert arrived — and for instinct triggers, signals that the escalation is judgment-based rather than evidence-based.

Field 2: Entity. The primary entity (user, device, IP, application) and any correlated entities. This tells L2 what to investigate.

Field 3: Evidence checked. What the L1 analyst already verified — sign-in history, MFA method, related alerts, geographic location, device compliance. This prevents L2 from duplicating L1 work.

Field 4: Question for L2. The specific thing the L1 analyst couldn't determine. Not "is this malicious?" but "is this sign-in from a residential proxy consistent with AiTM token capture, or does this user use a VPN that routes through residential IPs?" A specific question focuses the L2 investigation and makes the escalation actionable.

NE's escalation template

NE's Sentinel ticketing workflow includes a structured escalation comment template that analysts populate for every escalation. The template enforces the four fields — the analyst can't submit the escalation without all four populated. This prevents the "looks suspicious, escalating" pattern that forces L2 to restart from zero.

The template takes 2-3 minutes to populate. For capability escalations, the evidence section describes what L1 checked during the 15 minutes. For pattern escalations, the evidence section lists the correlated alerts and the time window. For instinct escalations, the evidence section describes what the analyst checked (which was clean) and the observation that triggered the escalation.

Here's a complete instinct escalation using the template:

Trigger: Instinct. Entity: c.richardson@ne.com (Finance team, Accounts Payable). Evidence checked: Sign-in history — normal device (DESKTOP-CR01), normal IP (corporate VPN exit). MFA succeeded interactively. No related alerts in 24 hours. No impossible travel. Device compliant. Inbox rule created at 06:47 — new folder 'Archive-2026', condition matches 'invoice' OR 'payment'. Rule is syntactically legitimate. Question for L2: The rule was created 90 minutes before the user's typical 08:15 start time. Is the sign-in session at 06:47 consistent with the user's historical early-morning patterns, or does the session show characteristics (token age, refresh pattern, client app) that suggest session replay rather than a genuine interactive sign-in?

That question is specific. It tells L2 exactly what to check next. It saves L2 from repeating the sign-in history, MFA, and device checks that L1 already completed. The L2 analyst opens the escalation and knows within 30 seconds what they need to investigate.

Measuring escalation quality

Escalation accuracy measures whether escalations were warranted — an indicator of L1 triage quality and framework effectiveness.

Escalation accuracy rate

For capability and pattern escalations, accuracy is measured as: what percentage resulted in L2 determining the alert genuinely required L2 investigation (not reclassifiable at L1)? A healthy rate is 60-80%. Below 50% suggests the triage framework needs refinement or L1 training needs attention. Above 90% suggests L1 might be under-escalating.

Instinct accuracy (tracked separately)

Instinct escalation accuracy is tracked as a separate metric: what percentage of instinct escalations resulted in L2 finding something that warranted investigation? A healthy rate is 20-40%. Yes, most instinct escalations turn out benign. That's by design. The instinct trigger catches the 1-in-5 that would otherwise be closed — and that 1-in-5 is where novel attacks hide. An instinct accuracy rate of 100% means analysts are only escalating on instinct when they're already certain it's malicious — which means they're not using the trigger for genuine uncertainty.

NE reviews escalation metrics monthly as part of the L3 quality review. The review takes 1-2 hours and examines the full month's escalation data across all three trigger types. The metrics drive two actions: high capability-escalation volume for a specific alert type suggests the triage framework needs a new decision path for that type. Low instinct-escalation volume suggests analysts may not be comfortable using the trigger, which requires cultural reinforcement from the SOC lead.

Run this query to measure your escalation patterns — it reveals how many alerts move from L1 to L2 and what happens to them:

// What percentage of alerts escalate, and what's the outcome?
SecurityIncident
| where TimeGenerated > ago(30d)
| where Status == "Closed"
| summarize
    Total = count(),
    TP = countif(Classification == "TruePositive"),
    FP = countif(Classification == "FalsePositive"),
    BTP = countif(Classification == "BenignPositive")
    by Severity
| extend EscalationRate = round(100.0 * TP / Total, 1)
| sort by Severity asc

If your High-severity escalation rate is below 15%, your L1 analysts may be closing alerts that warrant investigation. If it's above 40%, your detection rules may be over-classifying severity. Both signals drive specific framework adjustments.