The Detection Coverage Gap Is Real — But Narrower Than It Looks
Enterprise SOC teams at large financial institutions and technology companies operate with resources that mid-market security teams will never have: dedicated threat intelligence analysts who maintain custom MITRE ATT&CK coverage maps, SIEM engineers who write and test detection rules full-time, threat hunters who run proactive queries against months of retained log data. The gap between their detection posture and a mid-market team with two analysts and a default EDR policy is real.
But it is narrower than the vendor landscape makes it appear. The enterprise tools — enterprise SIEM deployments, extended detection and response (XDR) platforms, 24/7 MDR contracts — are priced for the assumption that every possible attack surface needs coverage simultaneously. Mid-market companies do not have that attack surface. A 600-employee professional services firm running AWS, Okta, and CrowdStrike Falcon on roughly 700 endpoints has a well-defined perimeter for the attacks most likely to target them. You do not need to cover all 14 MITRE ATT&CK tactics with equal depth. You need to cover the five that kill-chain patterns for credential theft, lateral movement, and data exfiltration route through — reliably.
This article maps the practical coverage gap and the three-source approach that closes most of it without an enterprise budget.
What Enterprise Tools Are Actually Solving For
It helps to understand what problem enterprise security tools are designed to solve — because it is not always the same problem a mid-market SOC has.
A large enterprise running 50,000 endpoints, dozens of cloud accounts, and a mix of on-premises Active Directory and cloud identity providers needs detection tooling that scales horizontally: ingesting hundreds of millions of events per day, applying detection rules across heterogeneous environments, and maintaining separate detection workflows for different business units with different risk profiles. That is a data engineering problem as much as a security problem. The tools priced at $500K+ per year are solving that scale problem.
A 1,000-employee company running a moderately complex AWS environment and a single identity provider does not have that problem. Their SOC — realistically two to four analysts — has a signal-to-noise problem. They are receiving more alerts than they can triage, not more data than they can store. The solution to their problem is different: it is correlation fidelity at a volume their team can actually manage, not horizontal scaling of data ingestion.
Enterprise kill-chain detection tools also tend to assume dedicated tuning resources. The CrowdStrike Falcon Fusion SOAR playbooks, the Splunk ESCU detection rules, the Microsoft Sentinel analytics templates — these require configuration, ongoing maintenance, and institutional knowledge to operate well. A team that does not have a full-time detection engineer will find that the out-of-the-box configuration generates as much noise as a less sophisticated tool tuned to their environment.
The Three-Source Coverage Map
Most confirmed intrusions in the mid-market that reach the data exfiltration stage follow a recognizable sequence of technique stages. The exact techniques vary, but the logical chain is consistent: initial access via compromised credentials or phishing → execution on an initial foothold host → credential harvesting from the foothold → lateral movement to a higher-value target → privilege escalation → data staging and exfiltration. That sequence maps cleanly to signals observable across three data sources:
EDR Telemetry (CrowdStrike Falcon, SentinelOne, Carbon Black)
EDR covers the execution, credential harvesting, and endpoint-side lateral movement stages. Key technique signals: PowerShell download cradle execution (T1059.001), LSASS memory read (T1003.001), net use / psexec / WMI-based remote execution (T1021), scheduled task creation for persistence (T1053.005), and abnormal process trees indicating living-off-the-land binary (LOLBin) abuse. EDR gives you the host-level story — what ran, on which machine, at what time, initiated by which process.
CloudTrail / Cloud Audit Logs (AWS CloudTrail, Azure Activity Log, GCP Audit Logs)
Cloud audit logs cover the privilege escalation and data staging stages. Key technique signals: AssumeRole from anomalous geography (T1078.004), CreateAccessKey under a compromised or newly created IAM identity (T1098), PutBucketPolicy relaxing S3 permissions (T1562), repeated GetObject calls on data-rich buckets, and cross-account data movement via CopyObject to external buckets (T1537). Cloud audit logs give you the infrastructure-level story — what API calls were made, by which identity, and toward which resources.
Identity Logs (Okta System Log, Entra ID Sign-in Logs, AD Event IDs 4625/4648/4768)
Identity logs cover the initial access and lateral movement stages. Key technique signals: credential stuffing attempts producing sequences of Event ID 4625 (failed logon) followed by 4648 (explicit credential use), Okta authentication from new geographies or new device fingerprints without device trust, Entra ID sign-in risk elevation combined with conditional access policy bypass, Kerberoasting activity visible as unusual AS-REQ patterns for service principal names (T1558.003), and pass-the-hash lateral movement (T1550.002) detected via logon type 9 events in AD Security logs. Identity logs give you the account-level story — who authenticated, from where, and whether the authentication pattern matches established behavioral norms.
Where the Gap Remains Without Correlation
Each of these three sources, monitored independently, produces useful but incomplete coverage. A Tier-1 analyst reviewing the EDR console catches the LSASS dump but has no way to know whether an Okta authentication failure on the same account — visible only in a separate tool — preceded it by six minutes. A cloud security posture team reviewing CloudTrail catches the CreateAccessKey but does not know that a CrowdStrike detection for T1059.001 fired on the same user's laptop 18 minutes earlier.
The kill-chain is only visible as a kill-chain when the events from all three sources are evaluated together, with entity resolution applied to connect the same identity across all three event streams, and with a detection window that captures the temporal sequence as a coherent attack progression.
This is the specific gap that enterprise SOC teams close with SIEM correlation rules maintained by a detection engineering team. Mid-market teams close it by deploying a purpose-built cross-source correlation layer that handles the entity resolution and temporal windowing without requiring dedicated SIEM engineering resources to write and maintain the rules.
The MITRE ATT&CK Coverage Calculation
Rather than claiming comprehensive coverage, it is worth being precise about what three-source correlation actually covers in the ATT&CK framework.
Initial Access (TA0001): Strong coverage via identity log monitoring — credential stuffing (T1110), phishing with credential capture visible in Okta/Entra authentication events (T1566). Weaker coverage for supply-chain compromise (T1195) and drive-by compromise (T1189) — these require endpoint or web proxy telemetry not always available in a mid-market stack.
Execution (TA0002): Strong EDR coverage for T1059 (Command and Scripting Interpreter), T1053 (Scheduled Task), T1047 (WMI). The EDR behavioral engine catches these reliably even without custom rule tuning in modern Falcon and SentinelOne configurations.
Credential Access (TA0006): Strong coverage for T1003 (OS Credential Dumping) via EDR, T1558 (Steal or Forge Kerberos Tickets) via AD event logs, T1552 (Unsecured Credentials) partially via cloud audit logs. Weaker coverage for T1111 (MFA Interception) — this requires dedicated MFA proxy detection logic.
Lateral Movement (TA0008) and Privilege Escalation (TA0004): Cross-source correlation provides the strongest uplift here — these technique stages are precisely where single-source monitoring produces fragmented visibility.
This is not to say that three-source coverage is equivalent to enterprise-class detection depth across all ATT&CK tactics. Collection (TA0009) and Exfiltration (TA0010) have meaningful blind spots without DLP and network telemetry. But the three-source approach covers the confirmation stages that determine whether an attack reaches the exfiltration phase — and that is the decision point with the highest cost if missed.
Practical Implementation Sequence
For a mid-market SOC building out from a baseline of EDR-only monitoring, the coverage expansion sequence matters. Adding all three sources simultaneously and attempting to build correlation detection in parallel creates an overwhelming configuration burden.
A practical sequence: Start with EDR tuning to establish per-entity behavioral baselines — suppressing the known-benign process chains for your specific environment before adding cross-source complexity. Then bring identity logs online and build the entity resolution mapping between your EDR identities and your IdP accounts. Identity-to-EDR correlation alone closes a meaningful gap for the credential harvesting + lateral movement technique pairing. Then add cloud audit log ingestion and extend the correlation to the full three-source kill-chain.
At each stage, measure escalation-to-confirmed-incident ratio. That ratio is your signal that the correlation configuration is working. A ratio above 50% suggests well-tuned correlation; below 20% suggests the detection window or technique mapping needs tightening. Mid-market teams that rush to three-source correlation without establishing behavioral baselines per entity first will find themselves trading alert volume for correlation noise — a less severe but still unmanageable problem.
The coverage gap is real but tractable. Three sources, entity resolution, and technique-aware correlation windows get you to a detection posture that catches the dominant attack patterns — without the 20-person SOC or the seven-figure SIEM contract.