DE0.5 Why Vendor Detection Is Not Enough

What vendor detection does well

Microsoft’s built-in detection capabilities are substantial and should not be dismissed. Defender XDR correlates alerts across endpoint, identity, email, and cloud apps into unified incidents. Fusion uses machine learning to identify multi-stage attacks by linking low-confidence signals into high-confidence incidents. Entra ID Protection evaluates every authentication for risk using signals from Microsoft’s global threat intelligence — billions of sign-ins across millions of tenants. Defender for Endpoint detects known malware, behavioral patterns associated with common attack tools, and anomalous process execution. Defender for Office 365 detects phishing, malware attachments, and known malicious URLs.

These capabilities detect attacks that match patterns Microsoft has characterized across their global telemetry. If an attacker uses Mimikatz and the binary matches a known signature, Defender catches it. If an attacker connects from an IP address flagged across Microsoft’s threat intelligence network, Entra ID Protection raises the risk level. If a phishing email uses a domain that Microsoft has already identified as malicious, Defender for Office 365 blocks it.

For known threats with known signatures executed through known methods, vendor detection is effective.

Figure DE0.5 — Vendor detection covers known, globally characterized threats. Custom detection covers environment-specific, business-context threats. Together they provide defense in depth. Separately, each leaves significant gaps.

Five categories vendor detection cannot cover

Vendor detection fails in predictable categories. These are not vendor shortcomings — they are structural limitations of any detection system designed for the general case.

Category 1: Environmental context. Vendor rules do not know your environment. The impossible travel rule does not know that Morrison flies Edinburgh to Bristol three times per week. The inbox rule detection does not know that your finance team legitimately creates forwarding rules to a shared mailbox. The PowerShell execution rule does not know that your CI/CD pipeline runs 3,000 encoded PowerShell commands daily. Every vendor rule that fires on “suspicious” activity defines “suspicious” against a generic baseline — not your baseline. Custom rules incorporate your environment’s patterns: named locations, service accounts, known applications, business workflows, and legitimate exception patterns.

Category 2: Business-logic correlation. No vendor rule correlates identity risk with email content with recipient role. The CHAIN-HARVEST Phase 5 detection — “risky sign-in on the sender’s account + internal email with financial keywords + executive recipient” — requires knowledge of who your executives are, what constitutes financial keywords in your business, and which accounts are in your finance team. This is business logic. No vendor encodes it because every business is different.

Category 3: Crown jewel monitoring. Vendor rules do not know which servers contain your most sensitive data. Northgate’s crown jewels are the RHEL CAD/CAM rendering farm and the Birmingham defense enclave. A vendor rule detects “anomalous file access” generically — it does not distinguish between accessing the company intranet (low impact) and accessing the engineering drawings repository (critical impact). Custom rules weight severity by target: bulk file access from the engineering shares triggers a Critical alert; the same pattern from the intranet triggers Informational.

Category 4: Configuration drift detection. No vendor rule monitors your specific security configuration and alerts when it changes in ways that create exposure windows. The CHAIN-DRIFT scenario — a conditional access policy disabled for a device migration creating a 48-hour attack window — requires a custom rule that monitors your specific CA policies by name and correlates the change with exploitation attempts. Vendor rules detect attacks. Custom rules detect the conditions that make attacks possible.

Category 5: Third-party and hybrid data correlation. Vendor detections operate on Microsoft data. Your Palo Alto firewall logs (CommonSecurityLog), your Linux server audit logs (Syslog), your custom application logs (Custom_CL tables) — none of these are queried by vendor rules. Northgate’s RHEL servers, their SD-WAN flow data, and their VPN session logs are all in Sentinel but invisible to built-in detection. Custom rules bridge this gap: join DeviceLogonEvents (Microsoft) with CommonSecurityLog (Palo Alto) with Syslog (Linux) to detect attack chains that cross vendor boundaries.

The complementary model

The correct approach is not “vendor detection OR custom detection.” It is both. Vendor detection provides the broad baseline — known threats, known tools, globally characterized patterns. Custom detection provides the environmental specificity — your threats, your users, your infrastructure, your business logic.

In practice, this means: leave vendor detections enabled (they catch known threats at zero engineering cost), tune their thresholds to reduce false positives in your environment (DE9), and build custom rules for the five categories above (DE3 through DE8). The detection program metrics (DE0.8) measure the combined coverage of both vendor and custom rules.

For Northgate Engineering, vendor detection contributes approximately 10-15 techniques out of the 15 currently covered (most of the 23 rules are template-based or vendor pass-throughs). Custom detection engineering will add the remaining 30-40 techniques needed to reach the 35% target. The vendor provides the floor. The detection engineer builds the ceiling.

Troubleshooting: “Our vendor says their AI-powered detection covers everything”

No vendor detection system covers everything. AI-powered, ML-powered, and behavioral analytics all operate on the same constraint: they detect patterns they have been trained on or that are statistically anomalous against their baseline model. They do not detect attacks that use legitimate credentials, normal tools, and normal-looking behavior targeted at specific organizational assets. The more the attacker blends in with normal activity, the less any automated system — vendor or custom — can detect them based on behavior alone.

The detection engineer’s value is encoding organizational knowledge that no vendor has access to: who should access which resources, what constitutes suspicious scope for a given role, which configuration changes create exposure windows, and which data repositories are crown jewels. This knowledge lives in people’s heads until the detection engineer codifies it as KQL.

References used in this subsection

• Course cross-references: DE0.2 (CHAIN-HARVEST vendor detection failure), DE0.3 (CHAIN-MESH vendor detection failure), DE3-DE8 (custom rule building for all five categories), DE9 (tuning vendor templates)

Template rule performance: measuring what vendors provide

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// TEMPLATE vs CUSTOM: Compare alert quality between vendor templates and custom rules
SecurityAlert
| where TimeGenerated > ago(30d)
| extend RuleOrigin = iif(AlertName startswith "DE", "Custom", "Template")
| summarize
    TotalAlerts = count(),
    Resolved = countif(Status == "Resolved"),
    TP = countif(Classification == "TruePositive"),
    FP = countif(Classification == "FalsePositive")
    by RuleOrigin
| extend TPRate = iif(TP + FP > 0, round(TP * 100.0 / (TP + FP), 1), 0.0)