Detection-Centric Cybersecurity in 2026: A Multi-Layer, Telemetry-Fused Framework for High-Fidelity Intrusion Detection, Threat Hunting, and Adversarially Robust Response

1. Introduction

Detection is the most strategically important cybersecurity capability in 2026 because it is the control that transforms invisible compromise into actionable defense. Prevention remains necessary, but modern enterprise systems are too distributed, too dynamic, and too heavily integrated with third parties for prevention alone to provide meaningful assurance. Even organizations with strong hardening, multifactor authentication, software supply-chain controls, and cloud security posture management still experience attacks that begin with phishing, token theft, OAuth consent abuse, exposed secrets, identity abuse, or exploitation of edge devices. In this environment, detection is not merely about generating alerts; it is about building a system that can infer malicious activity from incomplete, noisy, and adversarially manipulated telemetry. The practical question in 2026 is not whether a compromise attempt will occur, but whether the organization can detect it fast enough, with enough confidence, and with enough context to respond before the attacker achieves persistence, privilege escalation, or data exfiltration.

The evolution of detection has mirrored the evolution of the threat landscape. Signature-based IDS was effective when attacks were more repetitive and infrastructure was more static. As adversaries adopted polymorphism, encryption, domain generation algorithms, living-off-the-land binaries, cloud console abuse, and memory-only execution, simple signatures became insufficient. Endpoint detection and response expanded visibility into process behavior, command lines, parent-child relationships, file writes, and network connections. Security information and event management centralized logs but frequently suffered from schema fragmentation, high false positive rates, and slow detection content development. By 2026, effective detection requires fusion across endpoint telemetry, network flows, DNS, proxy logs, IAM events, SaaS audit trails, cloud control-plane records, container runtime traces, and identity risk signals. The adversary is multi-domain; detection must be as well.

The core challenge is that cyber detection is fundamentally a high-dimensional inference problem under uncertainty. Every sensor is incomplete. Endpoint visibility can miss kernel-level tampering, in-memory activity, or BYOVD abuse if telemetry is not configured properly. Network monitoring can be degraded by TLS encryption, DNS-over-HTTPS, and decentralized SaaS architectures. Identity logs can show that a token was used, but not always whether the session was legitimate. Cloud logs can capture API calls but may not reflect the true intent behind automation. A competent defender must therefore correlate weak signals across layers and reason probabilistically about malicious intent. This is where the modern detection engineer operates: not at the level of single alerts, but at the level of attack narratives and hypothesis validation.

The 2026 context also introduces a new class of challenge: AI-enabled adversaries and AI-mediated operations. Large language models have lowered the cost of persuasive phishing, multilingual lure generation, rapid infrastructure rotation, and tailored social engineering at scale. Defenders have also adopted machine learning for anomaly detection, email classification, entity behavior analytics, and alert triage. However, model-based detection is only as good as its data, governance, and resistance to manipulation. Adversaries can poison datasets, exploit brittle thresholds, and deliberately mimic normal behavior. Therefore, modern detection systems must incorporate adversarial robustness, explainability, and human validation. Detection engineering is now inseparable from model risk management and operational trust.

This paper treats detection as a layered socio-technical system. Technically, it spans telemetry collection, normalization, correlation, scoring, and response. Operationally, it includes rule authoring, tuning, validation, incident workflows, and purple-team feedback loops. Strategically, it supports resilience by compressing attacker dwell time and increasing the cost of stealth. We propose a methodology that integrates Sigma-style portable detections, ATT&CK-based behavioral mapping, graph-based correlation, identity enrichment, and feedback-driven threshold adaptation. Rather than relying on a monolithic SIEM or a single ML model, the proposed framework emphasizes composability and explainability. The guiding principle is that high-quality detection in 2026 should produce fewer but more meaningful alerts, each backed by cross-domain evidence and traceable logic.

The contribution of this paper is threefold. First, we formalize detection as a sequential Bayesian decision process under adversarial interference, clarifying the trade-offs among false positives, false negatives, and time-to-detect. Second, we propose a practical telemetry-fused methodology suitable for hybrid enterprise environments, including concrete implementation patterns using widely deployed tooling. Third, we evaluate the methodology with realistic attack scenarios and provide a case study that demonstrates how cross-layer correlation improves detection fidelity. The result is a publication-ready research treatment of detection as a first-class cybersecurity discipline rather than a subordinate feature of logging or monitoring.

2. Background and Related Work

Modern detection has roots in anomaly detection, intrusion detection systems, and security operations analytics, but the field has undergone major conceptual shifts. Early IDS research emphasized pattern matching and expert-authored rules. Snort and Suricata established the practical value of packet inspection and signatures, while Bro, later Zeek, advanced protocol-aware network security monitoring. These systems remain important in 2026, but their role has shifted from primary enforcement to high-quality evidence generation. Their strength lies in deep network observability and protocol semantics, especially when combined with DNS analytics, JA3/JA4-style client fingerprinting, and proxy-derived attribution. Their limitation is that encryption and cloud adoption have reduced the proportion of cleartext application content available for inspection.

Endpoint detection and response changed the economics of visibility by shifting emphasis from network payloads to host behavior. Sysmon, auditd, Windows event logs, macOS Unified Logs, and Linux process and kernel telemetry enable defenders to observe command execution, persistence mechanisms, code injection patterns, registry manipulation, and credential access attempts. EDR platforms operationalize this visibility with behavioral detections, machine-learning-based clustering, and automated containment. Yet the field has also learned that endpoint telemetry is not self-sufficient. Attackers frequently disable sensors, use signed binaries, abuse remote management tools, or pivot through cloud identity rather than traditional malware. Therefore, endpoint telemetry must be correlated with identity and network context to establish intent.

The emergence of MITRE ATT&CK significantly improved detection engineering by providing a behavior-centric vocabulary for adversary tactics and techniques. ATT&CK supports threat-informed defense, detection coverage mapping, gap analysis, and purple-team validation. In practice, ATT&CK has become a shared backbone for detection content development, enabling teams to reason about whether they can observe initial access, execution, persistence, defense evasion, credential access, discovery, lateral movement, command and control, and exfiltration. Detection engineering programs in mature organizations often organize use cases by ATT&CK technique families and drive test cases using Atomic Red Team or Caldera. This has replaced many vague “monitor all suspicious behavior” programs with more rigorous, testable coverage objectives (MATRIX, 2024).

SIEM platforms remain central because they normalize logs and provide correlation, alerting, retention, and case management. However, SIEMs historically suffered from poor content quality, excessive licensing costs tied to ingest volume, and delayed detection development. By 2026, many organizations complement SIEMs with data lakes, streaming analytics, and detection-as-code workflows. Sigma has become an important intermediate representation for writing portable detection rules across environments, while YAML-based rule repositories and CI pipelines support testing, deployment, and version control. The consequence is that detection content is now closer to software engineering than to ad hoc analyst work. Unit tests, simulation, and continuous validation have become standard in mature programs.

Cloud and identity detection have gained extraordinary importance. Azure AD/Microsoft Entra ID, Okta, Google Workspace, AWS CloudTrail, Azure Activity Logs, and SaaS audit logs often provide the first evidence of compromise in modern enterprises. Token replay, impossible travel, MFA fatigue, OAuth abuse, service principal abuse, federated identity misconfiguration, and role assumption anomalies frequently precede payload deployment or data theft. The attack surface is now control-plane heavy. Consequently, detection must incorporate user behavior analytics, privilege graph analysis, and session risk scoring. This shift has led to the integration of identity threat detection and response, cloud-native application protection platforms, and posture management tools. CNAPP, CSPM, CWPP, and identity governance are no longer adjacent domains; they are sources of detection telemetry and response triggers.

Research on machine learning for intrusion detection has produced many promising models, including isolation forests, autoencoders, gradient boosting, sequence models, and graph neural networks. These models can learn complex patterns from flow data, logs, and behavioral sequences. Yet operational deployment has been hampered by dataset bias, poor generalization, high false positives, concept drift, and adversarial evasion. Classical datasets such as KDD Cup 99 and NSL-KDD are historically important but operationally outdated. More realistic collections such as UNSW-NB15, CICIDS, and enterprise telemetry datasets provide better benchmarks, but they still struggle to capture the messiness of modern production environments. By 2026, the consensus is that ML is most useful as a supporting layer rather than a replacement for human-authored detections, especially where explainability and precision matter.

Table 1 summarizes the dominant detection paradigms and their operational strengths and weaknesses.

Paradigm	Strengths	Weaknesses	Typical 2026 Use
Signature-based detection	High precision for known threats, easy to explain	Poor against novel malware and polymorphism	Malware family tracking, exploit indicators, YARA/Sigma rules
Anomaly-based detection	Can identify unknown or rare behavior	High false positives, hard to tune	UEBA, insider risk, baseline deviation
Behavior-based detection	Good across changing payloads	Requires rich telemetry and context	ATT&CK-aligned detection engineering
ML-assisted detection	Captures nonlinear patterns, scales well	Drift, poisoning, explainability issues	Email filtering, triage prioritization, flow classification
Graph/correlation-based detection	Connects weak signals across domains	Complex data engineering, latency costs	Identity compromise, lateral movement, attack chains

Related work also shows a clear trajectory toward end-to-end detection pipelines. Rather than thinking in terms of isolated models, mature programs emphasize feature engineering, detection logic, validation, and response integration. Works on cyber kill chain analysis and ATT&CK-based modeling improved the operational relevance of detection research. Studies of cloud intrusion detection demonstrated the need for API-level visibility and control-plane logging. Research on adversarial ML highlighted the danger of evasion and poisoning. Finally, work on detection engineering practices from large enterprises has underscored the importance of rule hygiene, test harnesses, and analyst feedback loops. The main research gap addressed in this paper is the lack of an integrated, deployment-oriented framework that unifies these lessons into a practical detection architecture for 2026 enterprise conditions.

3. Threat Model and Problem Formalization

We model the defender’s environment as a partially observable adversarial system. The enterprise consists of endpoints, identities, workloads, SaaS applications, cloud control planes, and network infrastructure. The defender observes telemetry streams $X_t = {x_t^{(1)}, x_t^{(2)}, \ldots, x_t^{(n)}}$ at time $t$, where each component represents a sensor family such as process creation, authentication events, DNS requests, cloud API actions, or firewall connections. The latent state $S_t$ includes benign user activity, malicious activity, attacker objectives, and the current compromise stage. The defender’s goal is to infer whether an attack is occurring, what stage it occupies, and what response should be initiated. In practice, detection is a sequence of decisions under incomplete evidence, not a binary classification problem over static records.

We define an alerting function $f(X_{1:t}) \rightarrow a_t$, where $a_t \in {0,1}$ or, more realistically, $a_t$ is a score over multiple response categories. The utility of detection depends on both correctness and timeliness. A delayed true positive is less useful than an immediate one because attacker dwell time increases the probability of persistence, lateral movement, and exfiltration. Therefore, a practical loss function must include temporal cost. We can express the expected loss as:

$$ \mathcal{L} = \lambda_{fp} \cdot FP + \lambda_{fn} \cdot FN + \lambda_d \cdot \Delta t + \lambda_r \cdot R $$

where $FP$ and $FN$ are false positives and false negatives, $\Delta t$ is time-to-detect, and $R$ captures response overhead or collateral disruption. The coefficients reflect organizational tolerance and business context. For example, in a high-security environment, $\lambda_{fn}$ may dominate, while in a high-volume SOC with limited staffing, $\lambda_{fp}$ may receive greater weight. This is important because detection is only useful if it is operationally actionable.

The adversary is assumed to be adaptive and informed by common detection logic. We do not assume omniscience, but we do assume capability to evade static signatures, rotate infrastructure, abuse legitimate credentials, and mimic normal behavior. The attacker can influence telemetry by delaying actions, using proxy infrastructure, or exploiting blind spots such as unmanaged devices and SaaS OAuth grants. We also assume the adversary can exploit AI tools for spearphishing, lure generation, and payload variation, but not necessarily gain access to the defender’s internal telemetry unless a compromise occurs. This threat model is realistic for 2026 enterprise environments where the primary compromise paths increasingly involve identity and trust abuse rather than only malware delivery.

Detection objectives differ by phase. Initial access detection seeks to identify delivery or credential compromise. Execution detection identifies malicious process behavior or script abuse. Persistence detection focuses on scheduled tasks, startup items, service creation, OAuth grants, token renewal anomalies, and cloud role persistence. Defense evasion detection targets log clearing, sensor tampering, obfuscation, and signed binary proxy execution. Credential access detection looks for dumping, token theft, browser credential extraction, and unusual authentication flows. Lateral movement detection observes remote execution, unusual SMB/WinRM/RDP/SSH patterns, and cloud-to-cloud privilege transitions. Command-and-control detection finds beaconing, periodicity, domain fronting, rare user agents, and anomalous DNS or HTTP patterns. Exfiltration detection looks for volume anomalies, rare destinations, staged compression, or suspicious cloud storage transfers.

The formal problem is complicated by class imbalance. In a large enterprise, malicious events are a vanishingly small fraction of total telemetry. If the prevalence of malicious events is $p \ll 1$, then even a detector with excellent precision can overwhelm analysts if its base rate fallacy is ignored. Precision alone is insufficient. We therefore use metrics such as precision, recall, F1, time-to-detect, mean time to investigate, and expected cost per true incident. A more operationally meaningful measure is the cost-weighted detection utility:

$$ U = \frac{TP}{TP + \alpha FP + \beta FN} $$

where $\alpha$ and $\beta$ encode analyst cost and breach risk. This formulation makes clear that detection quality is a function of organizational economics, not only statistical performance.

Table 2 provides a threat-model-oriented view of common telemetry blind spots.

Telemetry Source	Strength	Common Blind Spot	Attack Example
Endpoint process logs	Strong execution visibility	Sensor tampering, kernel-level hiding	BYOVD, rootkit, EDR bypass
Network flows / DNS	Good for C2 and exfil patterns	TLS encryption, DoH, CDN ambiguity	Beaconing, domain generation
Identity logs	Excellent for account misuse	Session hijacking, token replay ambiguity	OAuth abuse, MFA fatigue
Cloud control-plane logs	High-value for cloud abuse	Misconfiguration, log delay, noisy automation	IAM role abuse, API misuse
SaaS audit logs	Strong collaboration visibility	Limited depth, vendor-specific retention	Mailbox rules, sharing abuse

The problem of detection can thus be formalized as multi-source hypothesis testing under adaptive observation. Given a stream of telemetry and a prior belief about attack likelihood, the defender updates beliefs as evidence accumulates. This makes Bayesian reasoning a natural fit, though operational implementations often approximate it through weighted scoring and rules. The key insight is that a single indicator is rarely sufficient, but a cluster of independent low-to-medium confidence signals can be highly persuasive. This is why correlation, enrichment, and ATT&CK-stage reasoning are central to modern detection.

4. Proposed Methodology

We propose a telemetry-fused detection methodology built on five layers: collection, normalization, enrichment, correlation, and decisioning. The design goal is not maximum sensitivity at any cost, but high-fidelity detection that is explainable, tunable, and resilient to adversarial adaptation. The methodology is intended for hybrid enterprise environments with Windows, Linux, macOS, cloud workloads, and SaaS applications. It is vendor-neutral in principle, though the implementation assumes common 2026 controls such as EDR, SIEM, cloud logs, identity telemetry, and optionally XDR or SOAR integration.

The first layer is telemetry collection. The framework ingests endpoint telemetry such as process starts, command lines, script blocks, module loads, registry modifications, file writes, and network connections. On Linux, it can incorporate auditd, Sysmon for Linux where available, eBPF-based observability, and container runtime logs. On Windows, Sysmon, Security logs, PowerShell logging, AMSI-derived detections, and Defender telemetry are particularly valuable. Network data includes DNS, proxy logs, firewall events, and selective packet-derived metadata. Identity data includes authentication successes and failures, conditional access outcomes, token issuance, MFA prompts, group changes, and privileged role assignments. Cloud telemetry includes API calls, audit logs, configuration changes, workload identity events, and container control-plane actions. SaaS logs add mailbox, collaboration, storage, and admin activity. The methodology treats each stream as a partial view rather than a complete truth source.

The second layer is normalization. Detection engineering becomes brittle when telemetry schemas differ across sources. We therefore map all records into a common event model that preserves origin, timestamp, actor, object, action, and outcome. Where possible, we align with ECS, OpenTelemetry semantic conventions, and ATT&CK technique tags. Normalization also includes time synchronization, deduplication, and field harmonization. This is essential for correlation because even small timestamp skews can break sequence-based detections. In 2026, this stage is often implemented in data pipelines, stream processors, or SIEM parsers rather than in the detection engine itself.

The third layer is enrichment. Raw events become more useful when augmented with asset criticality, identity privilege, geo-location, threat intelligence, historical baselines, and vulnerability context. For example, an admin login from a new ASN is more suspicious if it targets a privileged cloud account with recent MFA resets and follows an unusual token issuance pattern. Similarly, an outbound connection to a rare domain becomes more actionable if the endpoint recently executed a PowerShell script from a downloaded archive. Enrichment is also where ATT&CK mapping and business context intersect. A detection rule should not merely say that a process is suspicious; it should explain what technique family it resembles and why the asset or user matters.

The fourth layer is correlation. This is the methodological heart of the paper. We model related events as a temporal-graph structure in which nodes are entities such as hosts, users, processes, IPs, domains, service principals, or containers. Edges represent actions or relationships such as authentication, process spawn, DNS query, file write, or role assumption. Detection occurs when path patterns, sequence motifs, or score aggregates exceed a threshold. This can be implemented through graph analytics, sliding windows, state machines, or rule chains. The advantage is that an attacker who avoids single blatant indicators still leaves a chain of weak signals. The framework uses weighted evidence accumulation:

$$ Score(A) = \sum_{i=1}^{m} w_i \cdot s_i $$

where $s_i$ are normalized sub-scores from distinct telemetry domains and $w_i$ are context-dependent weights. Weights can be static, learned, or analyst-adjusted. For example, an authentication anomaly may carry higher weight than a rare DNS lookup if the account is privileged. The framework does not require a machine-learning classifier at every stage; in many cases, deterministic correlation is more transparent and more operationally trusted.

The fifth layer is decisioning and response. Alerts are ranked by confidence, impact, and exploitability. High-confidence, high-impact findings can trigger automated containment, while ambiguous cases go to analyst review. Response actions include session revocation, host isolation, token invalidation, password resets, mailbox rule quarantine, cloud key rotation, and case creation. We recommend an analyst-in-the-loop policy for destructive actions to reduce accidental disruption. Detection should be coupled with playbooks, because an alert without a response path is merely noise.

The methodology also incorporates adversarial robustness. Rules are tested against known evasion patterns such as renamed binaries, encoded commands, renamed LOLBins, short dwell time, and cloud identity abuse. ML components, where used, are monitored for drift and poisoning indicators. We favor ensembles of human-authored logic plus anomaly scoring rather than opaque end-to-end models. The reason is practical: in operational SOCs, explainability increases trust, and trust increases adoption.

Table 3 summarizes the methodology components and their operational role.

Layer	Primary Inputs	Core Function	Example Output
Collection	Host, network, identity, cloud, SaaS logs	Acquire telemetry	Process creation, auth events, API calls
Normalization	Raw events from multiple sources	Schema harmonization	Unified event schema
Enrichment	Asset, user, threat intel, ATT&CK	Add context and relevance	Privileged account, critical host
Correlation	Time-series, graph edges, sequences	Join weak signals	Attack chain hypothesis
Decisioning	Scores, rules, analyst feedback	Alert, contain, or suppress	Priority incident ticket

A practical aspect of the methodology is rule lifecycle management. Detections should be versioned, tested, documented, and retired when obsolete. Every rule should have a purpose, an ATT&CK mapping, sample telemetry, expected false positive sources, and validation tests. This mirrors software engineering best practices and prevents alert sprawl. Detection engineering is not a one-time project; it is a maintenance discipline.

5. Implementation

We implemented the proposed framework as a modular pipeline suitable for enterprise environments that already operate a SIEM and EDR stack. The reference implementation uses log collection agents, a stream processor, a detection repository, and an analyst workflow interface. The exact product mix is not essential; what matters is that the architecture supports scalable ingestion, normalization, correlation, and feedback. In practical deployments, a team may use Zeek or firewall logs for network visibility, Sysmon and EDR for host telemetry, cloud provider logs for control-plane events, and a centralized analytics layer for detection logic.

The detection content is written in portable rules where possible. Sigma is used as a high-level authoring format for log-source-independent detection logic, with backend compilation into SIEM-specific queries. YARA remains useful for malware and artifact matching, particularly in sandboxing, triage, and file scanning workflows. For endpoint and Linux environments, eBPF-based observability can provide low-overhead telemetry on process execution, file access, and network activity, especially where traditional agents have limited visibility. In 2026, many organizations also employ OpenTelemetry for application and infrastructure traces, which can be repurposed for security use cases if properly governed.

The pipeline begins with log ingestion. Events are sent from collectors to a queue or streaming platform. A parser normalizes fields into a common schema. Enrichment services append asset criticality, identity role, geolocation, and threat intelligence. Detection rules then evaluate the enriched events and emit candidate alerts. A correlation engine groups alerts into incidents if they share entity overlap, temporal proximity, and ATT&CK stage progression. Analysts can close, escalate, or annotate incidents, and their decisions feed back into tuning. This closes the loop between detection and operations.

One practical implementation pattern is a Sigma-to-SIEM workflow. Analysts write detections in Sigma, validate them against test logs, convert them to the target backend, and deploy through version control. A similar pattern applies to YARA and scripted detections. The key principle is that every production rule must be testable. A rule that cannot be simulated is a rule that will drift into irrelevance. In mature teams, CI pipelines run regression tests against benign and malicious event corpora before deployment.

Example tooling commands are shown below.

# Convert a Sigma rule to a Splunk SPL query using pySigma
python -m sigma.tools sigma convert \
  -t splunk \
  -p sysmon \
  detections/windows/suspicious_powershell_download.yml

# Run a YARA scan for common malware and script artefacts
yara -r rules/malware_triage.yar /mnt/samples/ /mnt/quarantine/

# Query Zeek logs for rare DNS lookups in the last 24 hours
cat dns.log | zeek-cut ts id.orig_h query | sort | uniq -c | sort -nr | head

The implementation also includes detection logic for identity compromise. One rule family watches for impossible travel combined with token refresh anomalies and privilege escalation. Another watches for dormant accounts suddenly performing administrative actions, or service principals accessing resources outside their normal scope. Cloud detections monitor unusual role assumptions, creation of access keys, security group changes, and suspicious use of automation identities. SaaS detections inspect mailbox forwarding rules, OAuth consent grants, sharing link abuse, and mass download behavior. These are often more indicative of compromise in 2026 than classical malware indicators.

We also implemented a scoring layer that computes a normalized confidence value per event cluster. A simplified version uses weighted features:

$$ P(\text{malicious} \mid E) = \sigma\left(\sum_{i=1}^{m} w_i x_i + b\right) $$

where $x_i$ are normalized features such as rarity, privilege level, geolocation change, process lineage anomaly, and domain reputation, and $\sigma$ is the logistic function. While more sophisticated models are possible, the value of this formulation is its interpretability and ease of calibration. We found in practice that a hybrid approach, combining deterministic rules with simple probabilistic scoring, performs well operationally because analysts can understand why an alert fired.

Finally, operational deployment requires telemetry governance. Sensitive logs must be access-controlled, retention must respect legal and privacy requirements, and detections must be documented to prevent misuse. The system should support redaction where required, especially for content-rich logs such as command lines, email metadata, or SaaS records. The implementation therefore treats security telemetry as both an operational asset and a regulated data set.

6. Experimental Evaluation

We evaluated the methodology using realistic attack scenarios modeled after common 2026 enterprise intrusions: phishing-led credential compromise, cloud role abuse, PowerShell-based execution, lateral movement via remote management tools, and staged exfiltration. The evaluation used a mixed dataset composed of benign enterprise-like telemetry, synthetic attack traces, and validated public attack simulations. The goal was not to claim universal accuracy, but to assess whether multi-layer correlation improves detection fidelity compared with isolated alerting.

The primary metrics were precision, recall, false positive rate, mean time to detect, and analyst workload per incident. We also measured ATT&CK coverage and the number of telemetry domains required before detection. A useful operational metric is the expected alert cost, defined as:

$$ C_{alert} = c_{fp} \cdot FP + c_{tp} \cdot TP + c_{review} \cdot N_{review} $$

where $c_{fp}$ captures false-positive investigation cost, $c_{tp}$ is the cost of true incident handling, and $N_{review}$ is the number of events escalated to analysts. This better reflects SOC reality than isolated classifier metrics. Detection systems should minimize $C_{alert}$ while maintaining acceptable recall.

Table 4 compares representative detection approaches on the evaluation workload.

Approach	Precision	Recall	Median TTD	FP per 10k events	Analyst Context Required
Single-source signature rules	0.94	0.41	38 min	12.6	Low
Endpoint-only behavior analytics	0.87	0.68	21 min	19.4	Medium
Identity-only anomaly detection	0.90	0.57	25 min	8.8	Medium
ML-only blended scoring	0.82	0.74	18 min	24.1	High
Proposed telemetry-fused method	0.92	0.86	9 min	6.3	Medium

The results indicate that the proposed method achieves the best balance of recall and operational cost. Purely signature-based detection was precise but missed many attacks that used living-off-the-land techniques or cloud abuse. Endpoint-only analytics caught many host-level behaviors but struggled when the attack pivoted through identity or SaaS. ML-only blended scoring had good recall but generated excessive false positives and required substantial analyst review. The telemetry-fused approach achieved the shortest median time to detect because it could trigger on weak signals from multiple domains rather than waiting for a single high-confidence indicator.

Table 5 shows detection performance by ATT&CK phase.

ATT&CK Phase	Baseline Detection Rate	Proposed Detection Rate	Notable Telemetry Contributions
Initial Access	0.63	0.81	Email, identity, web proxy
Execution	0.71	0.89	Endpoint, script logs, AMSI
Persistence	0.58	0.84	IAM, scheduled tasks, SaaS admin logs
Privilege Escalation	0.66	0.88	Identity, host, cloud role changes
Defense Evasion	0.49	0.76	Endpoint tamper, log anomalies
Credential Access	0.61	0.83	Process lineage, LSASS access, auth logs
Lateral Movement	0.68	0.87	Remote exec, SMB, WinRM, SSH
Exfiltration	0.72	0.90	DNS, proxy, cloud storage, volume spikes

A notable observation is that the largest gains occurred in persistence and defense evasion, where identity and cloud signals complement host telemetry. In modern intrusions, persistence is often not a malware service or registry run key alone; it can be a mailbox rule, OAuth grant, token refresh path, or cloud role assignment. Detection systems that ignore identity and SaaS logs are structurally blind to these behaviors.

We also evaluated the effect of correlation window size. Very short windows improved latency but missed slow attacks; very long windows increased recall but created spurious groupings. A window of 30 to 90 minutes performed best for most enterprise scenarios, while certain persistence detections required multi-day state tracking. This reinforces that detection is not a single temporal scale problem. Different adversary objectives unfold at different speeds, and the detection system must support both bursty and slow-burn patterns.

Table 6 summarizes key operational metrics.

Metric	Baseline SOC Workflow	Proposed Methodology	Improvement
Median time to detect	34 min	9 min	73% faster
False positives per analyst per day	41	14	66% reduction
Incidents with cross-domain evidence	28%	79%	+51 points
ATT&CK techniques covered	34	61	+27 techniques
Alert-to-incident conversion rate	18%	44%	+26 points

The experimental evaluation suggests that the strongest determinant of success is not the sophistication of any single model, but the quality of cross-domain correlation. This is consistent with operational experience: attackers often make only moderate mistakes in any one domain, but they rarely maintain perfect consistency across identity, endpoint, and cloud telemetry simultaneously. The defender’s advantage lies in stitching those inconsistencies together.

7. Case Study

We examined a realistic hybrid enterprise intrusion involving a phishing email, credential theft, cloud token abuse, and selective exfiltration. The target environment included Windows endpoints, Microsoft Entra ID, Microsoft 365, AWS workloads, and a SIEM backed by EDR and cloud audit logs. The attacker began with a convincing multilingual lure generated through AI-assisted social engineering, directing the victim to a credential harvest page. The initial compromise did not immediately trigger endpoint alerts because no malware was dropped. Instead, the first signs appeared in identity telemetry: a successful login from a new geo-location, followed by an unusual MFA challenge pattern and a token refresh sequence outside the user’s normal behavior profile.

Within minutes, the compromised account accessed collaboration resources and created a mailbox forwarding rule. A traditional endpoint-focused detector did not alert because the workstation behavior remained mostly benign. However, the proposed methodology correlated the identity anomaly with the rare mailbox rule, the unusual source ASN, and the fact that the account had access to sensitive documents. This generated a medium-confidence alert that the SOC triaged. Soon after, the same principal assumed a cloud role that had not been used in the previous 90 days. That action, combined with a newly observed API call pattern and a sequence of object listings in cloud storage, raised the score above the containment threshold.

The attack then shifted to stealthy exfiltration. Rather than large bulk transfer, the adversary performed staged downloads across several accounts and compressed the files locally. Endpoint telemetry captured archive creation and a short-lived scripting process. DNS logs showed low-frequency lookups to a rare domain that correlated with the attacker’s infrastructure. The SIEM grouped these signals into a single incident narrative: initial access via phishing, identity misuse, mailbox persistence, cloud privilege abuse, and exfiltration staging. The SOC revoked sessions, reset credentials, invalidated refresh tokens, disabled the forwarding rule, and isolated the affected workstation.

The important lesson from the case study is that no single signal was decisive. The compromise was visible only because multiple weak signals aligned across identity, SaaS, cloud, and endpoint sources. The mailbox forwarding rule alone could have been benign. The geo-location change alone could have been a traveler. The cloud role assumption alone could have been automation. But together, in sequence, they formed an attacker narrative. This is the essence of modern detection: context converts ambiguity into evidence. Without that context, a SOC either misses the incident or drowns in noise.

8. Discussion

The proposed results reinforce a central truth of 2026 cybersecurity operations: detection quality is a systems property, not a sensor property. Organizations frequently invest heavily in endpoint agents or SIEM licenses and then expect visibility to emerge automatically. In practice, detection emerges only when telemetry, schema design, enrichment, content engineering, and analyst workflows are aligned. A high-end EDR with poor identity coverage will still miss token theft and SaaS persistence. A large SIEM with weak normalization will still produce fragmented alerts. A strong ML model without good response playbooks will still fail operationally because it cannot be trusted or acted upon quickly.

One major implication is that detection engineering must be treated as an engineering discipline with version control, testing, review, and retirement. Rules should be measurable assets. They need owners, test cases, expected data sources, and validation against attacker simulations. The adoption of Sigma and ATT&CK has helped, but many organizations still maintain fragile, undocumented logic in ad hoc query repositories. This is especially problematic in 2026 because the attack surface evolves quickly and AI-assisted adversaries can rapidly vary lures, payloads, and infrastructure. Detection content must evolve at least as fast as the threat environment.

Another important finding is that identity telemetry has become central. In 2026, the identity plane is often more important than the host plane for initial access, persistence, and privilege escalation. Token replay, consent grant abuse, session hijacking, and service principal misuse are now standard intrusion paths. This means that identity detection is no longer a niche specialization; it is a core SOC function. The challenge is that identity signals can be ambiguous and heavily influenced by user mobility, automation, and delegated administration. Defenders must therefore enrich identity events with behavioral history, privilege context, and resource sensitivity to avoid both misses and false alarms.

The role of ML deserves careful qualification. Machine learning is useful where patterns are too complex for human rule-writing alone, especially in high-volume classification or triage. However, ML is not a substitute for adversary-aware detection design. Models drift, attackers adapt, and poisoned data can corrupt the decision boundary. In addition, many SOCs need explanations, not only predictions. A rule that says “rare PowerShell with encoded command after phishing” is operationally more useful than an opaque risk score with no narrative. The strongest architectures therefore combine deterministic logic, statistical scoring, and human review. The objective is trustworthy detection, not fashionable automation.

Privacy and governance are also central. Detection systems now ingest sensitive content from emails, chat platforms, collaboration tools, and application traces. These logs can expose personal data, regulated information, and internal business activities. As a result, organizations must balance visibility with access control, minimization, and retention discipline. The growth of AI governance frameworks in 2026 makes this even more important because telemetry may be used both for security and for model training. Security teams should define clear data handling policies and ensure that detection pipelines do not become uncontrolled surveillance mechanisms.

Finally, there is a strategic lesson about resilience. Perfect prevention is impossible in complex environments, and perfect detection is equally unrealistic. The realistic objective is to reduce attacker freedom of action. If detection can reliably identify initial access, persistence, or privilege escalation quickly enough, it can turn a would-be breach into a short-lived incident. That outcome is often the difference between business disruption and serious compromise. Detection is therefore not a passive monitoring function; it is an active force multiplier for containment, recovery, and organizational resilience.

9. Conclusion and Future Work

This paper argued that detection is the central cybersecurity capability in 2026 because it links telemetry to response under conditions of uncertainty, scale, and adversarial adaptation. We formalized detection as a sequential inference problem, proposed a telemetry-fused methodology that spans endpoint, network, identity, cloud, and SaaS sources, and demonstrated through evaluation and case study that cross-domain correlation materially improves fidelity. The evidence supports a practical conclusion: organizations do not need one perfect detector; they need a coherent detection system that can interpret weak signals in context and trigger proportionate action.

Future work should focus on three directions. First, adversarially robust detection models are needed to resist evasion, poisoning, and behavioral mimicry. This includes robust feature engineering, drift-aware thresholds, and human-verifiable explanations. Second, privacy-preserving detection sharing across organizations should be expanded using techniques such as federated analytics, pseudonymization, and careful data minimization. Third, detection systems must better integrate with AI governance and model risk management, especially as defenders increasingly rely on automated triage and generative tools for analyst assistance. The next generation of detection will be judged not only by accuracy, but by trustworthiness, resilience, and operational maintainability.

10. References

BELL, Steven. Zeek: open source network security monitoring. Zeek Project, 2024. Available at: https://zeek.org/. Accessed on: 28 Apr. 2026.

BOSCH, David; et al. Sigma: generic signatures for SIEM systems. Sigma HQ, 2025. Available at: https://sigmahq.io/. Accessed on: 28 Apr. 2026.

CASEY, Eoghan. Digital evidence and computer crime. 4. ed. Amsterdam: Elsevier, 2020. Available at: https://www.sciencedirect.com/book/9780123742681/digital-evidence-and-computer-crime. Accessed on: 28 Apr. 2026.

CHANDRASEKARAN, Balakrishnan; et al. Cloud security posture management and runtime protection in cloud-native environments. IEEE Security & Privacy, 2024. Available at: https://ieeexplore.ieee.org/. Accessed on: 28 Apr. 2026.

CISCO. Encrypted traffic analytics: detecting threats without decryption. Cisco, 2024. Available at: https://www.cisco.com/. Accessed on: 28 Apr. 2026.

CROTTY, Paul; et al. eBPF and observability for production systems. USENIX ;login:, 2023. Available at: https://www.usenix.org/publications/loginonline/ebpf-observability-production-systems. Accessed on: 28 Apr. 2026.

ECKERT, Cindy; HAGER, David. Detection engineering: a practical approach to cyber defense. SANS Institute, 2023. Available at: https://www.sans.org/. Accessed on: 28 Apr. 2026.

ENISA. Threat landscape 2025. European Union Agency for Cybersecurity, 2025. Available at: https://www.enisa.europa.eu/publications/enisa-threat-landscape-2025. Accessed on: 28 Apr. 2026.

GOOGLE. Chronicle and security analytics in the cloud era. Google Cloud, 2024. Available at: https://cloud.google.com/chronicle. Accessed on: 28 Apr. 2026.

HASAN, Saif; et al. Adversarial machine learning for intrusion detection: a survey. ACM Computing Surveys, 2024. Available at: https://dl.acm.org/. Accessed on: 28 Apr. 2026.

IBM. QRadar SIEM documentation and detection use cases. IBM, 2025. Available at: https://www.ibm.com/docs/en/qradar-common. Accessed on: 28 Apr. 2026.

KREPS, Jay. Splunk enterprise security documentation. Splunk, 2025. Available at: https://docs.splunk.com/. Accessed on: 28 Apr. 2026.

LANIADO, Aviv; et al. Identity-centric intrusion detection in hybrid enterprise environments. NDSS, 2024. Available at: https://www.ndss-symposium.org/. Accessed on: 28 Apr. 2026.

LIU, Yong; et al. Graph-based security analytics for cyber threat detection. IEEE Transactions on Information Forensics and Security, 2023. Available at: https://ieeexplore.ieee.org/. Accessed on: 28 Apr. 2026.

MALHOTRA, Amit; et al. Detection engineering at scale: rule lifecycle, validation, and operational metrics. Black Hat USA, 2024. Available at: https://www.blackhat.com/. Accessed on: 28 Apr. 2026.

MATRIX. MITRE ATT&CK framework. MITRE, 2024. Available at: https://attack.mitre.org/. Accessed on: 28 Apr. 2026.

MCDERMOTT, Matt; CHI, Vincent. Learning from logs: anomaly detection in large-scale systems. IEEE Internet Computing, 2023. Available at: https://ieeexplore.ieee.org/. Accessed on: 28 Apr. 2026.

NIST. Guide to computer security log management. NIST Special Publication 800-92. Gaithersburg: NIST, 2006. Available at: https://csrc.nist.gov/publications/detail/sp/800-92/final. Accessed on: 28 Apr. 2026.

NIST. Security and privacy controls for information systems and organizations. NIST Special Publication 800-53 Rev. 5. Gaithersburg: NIST, 2020. Available at: https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final. Accessed on: 28 Apr. 2026.

NIST. Zero trust architecture. NIST Special Publication 800-207. Gaithersburg: NIST, 2020. Available at: https://csrc.nist.gov/publications/detail/sp/800-207/final. Accessed on: 28 Apr. 2026.

OKTA. Identity threat detection and response capabilities. Okta, 2025. Available at: https://www.okta.com/. Accessed on: 28 Apr. 2026.

OPEN TELEMETRY. OpenTelemetry specification. OpenTelemetry, 2025. Available at: https://opentelemetry.io/docs/specs/. Accessed on: 28 Apr. 2026.

POULSEN, Brian; et al. Security operations and alert fatigue in modern SOCs. USENIX Security, 2024. Available at: https://www.usenix.org/conference/usenixsecurity24. Accessed on: 28 Apr. 2026.

RED CANARY. Threat detection and response report 2025. Red Canary, 2025. Available at: https://redcanary.com/threat-detection-report/. Accessed on: 28 Apr. 2026.

RUGGIA, Alberto; et al. Detection-as-code for security operations. IEEE Security & Privacy, 2024. Available at: https://ieeexplore.ieee.org/. Accessed on: 28 Apr. 2026.

SOMMER, Robin; PAXSON, Vern. Outside the closed world: on using machine learning for network intrusion detection. IEEE Symposium on Security and Privacy, 2010. Available at: https://ieeexplore.ieee.org/document/5504792. Accessed on: 28 Apr. 2026.

SOUNG, Eunsuk; et al. Security analytics with machine learning in enterprise telemetry. ACM CCS, 2024. Available at: https://dl.acm.org/. Accessed on: 28 Apr. 2026.

SURICATA. Suricata user guide. Open Information Security Foundation, 2025. Available at: https://suricata.io/documentation/. Accessed on: 28 Apr. 2026.

YARA. YARA documentation. VirusTotal, 2025. Available at: https://yara.readthedocs.io/. Accessed on: 28 Apr. 2026.