Detection at Scale in Cybersecurity: A Multi-Layer, Behavior-Centric Architecture for Adversary Detection Across Endpoint, Identity, Cloud, and Network Telemetry

1. Introduction

Detection is the most operationally important control in cybersecurity because it determines whether an organization learns about compromise early enough to contain it, investigate it, and recover with acceptable loss. Preventive controls remain necessary, but they are not sufficient in an environment where attackers routinely bypass perimeter assumptions, abuse valid credentials, and exploit trusted tooling rather than noisy malware. In practice, the question is not whether a determined adversary will attempt to evade controls, but whether the defender can detect enough of the attack chain to interrupt execution before the attacker reaches objectives such as persistence, privilege escalation, lateral movement, data theft, or destructive impact.

By 2026, the detection problem has become materially more complex than in the era of network-centric intrusion detection. Enterprise environments now span hybrid identity fabrics, ephemeral cloud workloads, SaaS services, container orchestration, remote endpoints, and encrypted east-west traffic. The adversary surface is no longer limited to exploit payloads or commodity malware; it includes identity abuse, OAuth consent attacks, token theft, MFA fatigue, cloud control plane misuse, supply-chain compromise, and misuse of legitimate administrative tools. At the same time, defenders face overwhelming telemetry volume, uneven data quality, and a market that often conflates visibility with detection maturity. A platform may ingest terabytes of logs, but if those logs are not normalized, enriched, correlated, and operationalized, the organization merely accumulates evidence of failure rather than actionable detection capability.

This paper treats detection as a rigorous engineering and inference problem. A useful detection system must balance conflicting objectives: high recall against stealthy adversaries, low false positives to preserve analyst attention, low latency to enable containment, and manageable cost to avoid telemetry and compute becoming the limiting factor. In mathematical terms, a detection engine can be modeled as a function $f: X \rightarrow Y$, where $X$ is a multivariate stream of events and $Y$ is a set of alerts, incidents, or risk scores. The ideal function would maximize expected utility under uncertainty. However, defenders operate in a partially observable environment where attackers adapt to the detection logic itself. This makes static signatures brittle, purely statistical anomaly detection noisy, and fully black-box machine learning systems difficult to trust operationally. Hence the need for hybrid designs.

The central thesis of this paper is that effective detection in 2026 requires a multi-layer architecture that fuses deterministic rules, ATT&CK-aligned behavioral hypotheses, graph-based entity correlation, identity and cloud context, and continuous validation through adversary emulation and detection testing. The paper proposes a structured methodology that starts from kill-chain semantics and maps them to concrete telemetry sources across endpoint, network, identity, cloud, and application layers. This methodology is not intended to replace existing SIEM, EDR, NDR, or CNAPP capabilities; rather, it provides a unifying detection engineering framework that reduces fragmentation and improves measurable performance across those domains.

Detection engineering has matured as a discipline over the last decade. Early security operations emphasized signatures and IOC matching. The industry then moved toward endpoint telemetry, behavioral analytics, and ATT&CK mapping. By 2026, leading organizations increasingly use layered detection pipelines that incorporate Sigma rules, KQL, SPL, EQL, YARA, Zeek scripting, Suricata signatures, cloud-native threat detections, and CI/CD-style regression testing. Yet operational maturity remains uneven. Many programs still fail because they over-rely on vendor detections, under-invest in normalization and entity resolution, or ignore the detection of identity abuse and cloud control plane events. This paper addresses those shortcomings by defining a system-level model and evaluating it against realistic adversary tradecraft.

The paper is organized as follows. Section 2 reviews the background, including the evolution of detection paradigms, major telemetry classes, and prior work on anomaly detection, ATT&CK-based analytics, and threat hunting. Section 3 formalizes the threat model and the detection problem. Section 4 proposes a methodology for building multi-layer detections using normalized telemetry, graph correlation, and risk scoring. Section 5 details implementation considerations for practical deployment. Section 6 presents an experimental evaluation using emulated intrusions and synthetic but realistic enterprise telemetry. Section 7 offers a case study that illustrates how weak signals become actionable when combined. Section 8 discusses limitations, operational trade-offs, and future directions such as AI-assisted detection engineering, eBPF telemetry, and post-quantum readiness. The conclusion summarizes the key findings and implications for practitioners.

2. Background and Related Work

Detection in cybersecurity has historically been shaped by the data available to defenders. In the 1990s and early 2000s, network-based intrusion detection systems relied on packet signatures and protocol anomalies. These systems were useful against known exploits but struggled with encrypted traffic, polymorphism, and attacker adaptation. Host intrusion detection expanded visibility to file integrity, system calls, and process behavior, while antivirus focused on known malware artifacts. As endpoint telemetry matured, defenders could observe command lines, parent-child process relationships, memory events, script execution, and persistence mechanisms. This shifted detection away from simple indicators of compromise and toward adversary behavior.

A major conceptual development was the rise of the MITRE ATT&CK framework, which provided a shared taxonomy for describing adversary tactics, techniques, and procedures. ATT&CK enabled defenders to express detections in behavioral terms rather than only in artifact terms. Instead of asking whether a hash is malicious, analysts could ask whether a process executed encoded PowerShell, whether a cloud principal created anomalous access keys, or whether a service account used atypical lateral movement paths. This shift is important because behavior persists even when artifacts change. ATT&CK has therefore become central to detection engineering, purple teaming, and coverage assessment (MITRE, 2024).

Table 1 summarizes major detection paradigms and their operational strengths and weaknesses.

Paradigm	Primary Telemetry	Strengths	Weaknesses	Typical Use
Signature-based detection	Hashes, byte patterns, YARA, IDS signatures	High precision for known threats	Brittle, evadable, limited context	Commodity malware, exploit detection
Rule-based behavioral detection	Endpoint logs, network flows, cloud audit logs	Explainable, tunable, operationally practical	Requires engineering effort and tuning	Lateral movement, persistence, identity abuse
Statistical anomaly detection	Baselines, time-series, embeddings	Can surface novel behavior	High false positives, context dependence	Insider threat, rare events, exfiltration
Graph correlation detection	Entities, relationships, sessions, identities	Captures multi-step intrusion chains	Requires robust entity resolution	Campaign detection, attack path analysis
Supervised ML classification	Labeled telemetry features	Can improve ranking and triage	Label scarcity, drift, opaqueness	Alert enrichment, prioritization
Hybrid detection pipelines	Multi-source telemetry	Balances recall, precision, and explainability	Complex architecture and governance	Mature enterprise detection programs

The literature on intrusion detection has long debated the trade-off between anomaly detection and misuse detection. Anomaly systems can theoretically catch unknown attacks but often generate excessive noise because normal enterprise behavior is diverse and dynamic. Misuse systems are precise but can be bypassed when attackers shift techniques. By 2026, the most successful operational systems are hybrid. They use deterministic rules for well-understood patterns, anomaly scoring for rare deviations, and graph correlation for weak-signal aggregation. This hybrid approach aligns with practical operations: a single suspicious event may not justify an alert, but a sequence of suspicious actions across identity, endpoint, and cloud planes can strongly indicate compromise.

The expansion of cloud and SaaS telemetry has also changed the detection landscape. Cloud audit logs such as AWS CloudTrail, Azure Activity Logs, Microsoft Entra ID logs, and Google Cloud Audit Logs are now essential sources for identity compromise, permission misuse, persistence, and exfiltration detection. Cloud-native tooling such as AWS GuardDuty, Microsoft Defender for Cloud, Wiz, Orca, and Prisma Cloud have popularized the idea of continuous posture and runtime detection, but they also introduce a risk of vendor siloing. Effective detection requires correlating cloud-native alerts with endpoint and identity telemetry, because attackers commonly traverse these layers in a single intrusion chain.

A second major development is the maturation of endpoint detection and response. Products in the EDR/XDR category observe process trees, command lines, DLL loads, registry changes, script execution, network connections, and file operations. These telemetry sources are suitable for behaviors associated with malware execution, credential theft, defense evasion, and persistence. However, attackers increasingly exploit legitimate tools, memory-resident techniques, and living-off-the-land binaries such as powershell.exe, rundll32.exe, reg.exe, wmic, mshta.exe, curl, wget, python, bash, and signed remote management tools. Detection therefore depends less on filenames and more on context: argument patterns, parent processes, user context, timing, destination reputation, and sequence of actions.

Network detection has similarly evolved. Traditional IDS signatures remain valuable for exploits and known malware beacons, but modern environments often require flow-based analytics, TLS fingerprinting, DNS analysis, proxy logs, and Zeek-derived protocol metadata. With encryption pervasive, defenders increasingly inspect metadata rather than payloads. JA3 and JA4-style TLS client fingerprinting, DNS anomaly detection, and netflow correlation are now common elements of network detection stacks. Nevertheless, the reliability of such signals depends heavily on normalization and contextual enrichment. A rare TLS fingerprint is not necessarily malicious; a rare TLS fingerprint combined with a newly created cloud identity, unusual endpoint process lineage, and an outbound connection to a newly registered domain is much more compelling.

The detection literature also includes work on threat hunting and detection-as-code. In this model, detections are version-controlled artifacts written in languages such as Sigma, EQL, SPL, KQL, or vendor-specific query formats. They are tested against emulated adversary activity, regression-tested when log schemas change, and deployed through continuous integration pipelines. This is operationally significant because detection logic is software. It has bugs, dependencies, schema assumptions, and lifecycle management requirements. Several organizations now treat detections as code assets with peer review, unit testing, and telemetry coverage matrices. This paper builds on that trend by making the relationship between telemetry, hypotheses, and measurable utility explicit.

Table 2 provides a concise comparison of major telemetry domains and their detection value.

Telemetry Domain	Example Sources	Detection Strengths	Common Gaps
Endpoint	Windows Security Logs, Sysmon, EDR, auditd, eBPF	Process trees, persistence, script execution, credential access	Agent bypass, log volume, kernel visibility constraints
Identity	Entra ID, Okta, AD logs, PAM, SSO logs	MFA abuse, impossible travel, token theft, privilege escalation	Identity sprawl, missing device context, federation complexity
Cloud	CloudTrail, Azure Activity, GCP Audit, Kubernetes audit	Control plane misuse, access key abuse, IaC drift, workload persistence	High event volume, schema variance, weak attribution
Network	NetFlow, Zeek, proxy, DNS, TLS metadata, IDS	Beaconing, exfiltration, C2 patterns, lateral movement	Encryption, NAT, proxy obfuscation, noisy baselines
Application/SaaS	Email, CRM, collaboration, CASB logs	Phishing, mailbox rule abuse, document exfiltration, OAuth abuse	API limitations, vendor lock-in, incomplete audit trails

Research into detection has increasingly intersected with machine learning and graph analytics. Feature-based classifiers can rank alerts and identify suspicious combinations of events, while graph models can connect identities, hosts, IPs, domains, and cloud resources into attack paths. However, operational deployment remains constrained by explainability, drift, and the difficulty of obtaining reliable labels. For this reason, the strongest practical systems in 2026 rarely rely on ML alone. Instead, they use ML as a scoring or triage layer on top of explicit hypotheses. This preserves interpretability while improving prioritization.

3. Threat Model and Problem Formalization

We define the defender’s objective as timely and accurate identification of malicious activity across a distributed enterprise environment under incomplete and noisy observation. The adversary is assumed to have one or more of the following capabilities: phishing users, stealing credentials, exploiting exposed services, abusing APIs, moving laterally through trusted remote administration tools, creating persistence in cloud and SaaS systems, and exfiltrating data under the cover of legitimate traffic. The adversary may also perform defense evasion by disabling logs, modifying endpoints, using encrypted channels, leveraging living-off-the-land binaries, or blending into routine administrative activity.

The environment is modeled as a heterogeneous set of assets $A = {a_1, a_2, \dots, a_n}$, identities $I = {i_1, i_2, \dots, i_m}$, and telemetry streams $T = {t_1, t_2, \dots, t_k}$. Each event $e \in T$ is a tuple containing timestamp, source, entity identifiers, action, attributes, and confidence. The detector computes a score $s(e)$ or a sequence score $s(E_{t_0:t_1})$ over a window of events. The objective is to maximize detection utility: $$ U = \alpha \cdot TP - \beta \cdot FP - \gamma \cdot FN - \delta \cdot L $$ where $TP$ is true positives, $FP$ is false positives, $FN$ is false negatives, and $L$ is latency or time-to-detect. The coefficients $\alpha,\beta,\gamma,\delta$ reflect the organization’s risk posture and analyst capacity.

A key difficulty is that not all malicious behavior is observable in a single layer. For example, a cloud persistence action may appear as a legitimate API call, an endpoint compromise may only show suspicious PowerShell, and a phishing-to-token-theft chain may be visible primarily in identity logs. Therefore, the detector must support cross-domain correlation. We define a detection hypothesis $H$ as a predicate over a sequence of events spanning multiple domains. For example: $$ H = H_{phish} \land H_{token} \land H_{persistence} \land H_{exfil} $$ where each sub-hypothesis is satisfied by a conjunction or weighted threshold of weaker signals.

The threat model also includes adaptive adversaries. If defenders deploy a deterministic rule that flags encoded PowerShell with a specific pattern, an attacker can switch to mshta.exe, rundll32.exe, WMI, or remote script execution. If defenders rely on a narrow anomaly model, the attacker can “train” the model by performing low-rate activity over time. Thus, detection must assume that the adversary observes, at least indirectly, some portion of the defensive posture. This is particularly true in cloud and SaaS environments where attackers can probe rate limits, error handling, and alerting behavior.

Table 3 formalizes the evaluation dimensions used throughout the paper.

Metric	Definition	Operational Meaning
Precision	$TP / (TP + FP)$	Fraction of alerts that are truly malicious
Recall	$TP / (TP + FN)$	Fraction of malicious events detected
F1-score	Harmonic mean of precision and recall	Balanced detection quality
Mean Time to Detect (MTTD)	Average time from first malicious event to alert	Speed of discovery
Analyst Load	Alerts per analyst per day	Operational sustainability
Coverage	Proportion of ATT&CK techniques with at least one valid detection	Breadth of observability
Cost per Detected Incident	Infrastructure and labor cost divided by true incidents detected	Economic efficiency

The formal problem is therefore not merely classification but sequential inference under resource constraints. The defender must infer whether a collection of benign-looking actions forms part of an intrusion campaign. A good detection system should tolerate low-confidence individual signals while amplifying their significance when they occur in the right temporal and relational context. This is why the proposed methodology emphasizes entity-centric correlation, temporal windows, and ATT&CK-aligned grouping rather than isolated event matching.

4. Proposed Methodology

The proposed methodology is a multi-layer detection architecture built around four principles: normalized telemetry, behavior-centric hypotheses, graph correlation, and continuous validation. The architecture is intended to sit above existing security tools rather than replace them. Its purpose is to unify the output of endpoint, identity, network, cloud, and SaaS monitoring into a coherent detection fabric.

4.1 Telemetry normalization and entity resolution

The first requirement is a common event schema. Raw logs differ substantially in field naming, timestamp precision, entity identifiers, and semantic richness. Detection quality suffers when analysts must write bespoke queries for every source. We therefore normalize events into a canonical schema with fields such as timestamp, actor, target, action, process, network, cloud_resource, auth_context, and source_system. In practice, many organizations map logs into ECS, OCSF, or an internal schema. The specific schema matters less than consistency and high-fidelity mapping.

Normalization must also resolve entities across layers. A single user may appear as an Entra ID principal, a Windows logon session, a cloud IAM role, and a SaaS identity. A single host may appear under multiple names across DHCP, DNS, EDR, MDM, and asset inventory systems. Without entity resolution, detection logic cannot reliably connect events. The methodology therefore builds an entity graph where nodes represent identities, hosts, domains, IPs, processes, cloud resources, and sessions, and edges represent observed relations such as logon, execution, connection, delegation, or API access.

4.2 Detection hypothesis generation

Instead of beginning with alerts, we begin with adversary hypotheses. For each ATT&CK technique of interest, we define one or more observable hypotheses. For example, credential dumping might be represented by LSASS access, suspicious handle opens, anomalous use of procdump, or network exfiltration of credential material. Cloud persistence may be represented by creation of access keys, service principals, OAuth grants, or mailbox forwarding rules. Each hypothesis is expressed as a weighted predicate over telemetry.

A generic hypothesis score can be written as: $$ S_H = \sum_{i=1}^{n} w_i \cdot x_i $$ where $x_i$ are normalized feature indicators and $w_i$ are weights learned from historical incidents or set by expert judgment. If $S_H \geq \theta$, the hypothesis is considered satisfied. This allows weak signals to combine into stronger evidence without requiring every event to be individually malicious.

4.3 Graph correlation and campaign stitching

Point detections often fail to capture campaigns. The methodology therefore includes a graph correlation layer that merges related alerts by shared entities, close temporal proximity, and causal sequence. For example, a phishing email that leads to OAuth consent, followed by mailbox rule creation and suspicious data access, may generate three low-severity events in different systems. Individually they may not justify a high-priority incident. Correlated together, they indicate a coherent intrusion path.

Graph scoring can be represented as: $$ G(V,E) = {v_1, v_2, \dots, v_n}, \quad score© = \sum_{v \in C} score(v) + \lambda \sum_{(u,v)\in E_C} w(u,v) $$ where $C$ is a connected component or subgraph of suspicious activity. This enables campaign-level prioritization, reducing analyst burden and improving triage.

4.4 Hybrid scoring and suppression logic

Purely rule-based systems over-alert, while purely anomaly-based systems overfit. The methodology therefore uses hybrid scoring. Deterministic rules identify high-confidence behaviors, while anomaly models rank unusual activity within an entity’s baseline. Suppression logic removes known benign administrative patterns, maintenance windows, service accounts with approved automation, and sanctioned vulnerability scanning. This is essential because mature environments contain many legitimate behaviors that resemble attack activity.

A practical implementation maintains three classes of detections: hard alerts for high-confidence malicious patterns, soft signals for weak anomalies, and contextual enrichments that are not alerts themselves but raise or lower the priority of other findings. This structure is operationally superior to alerting on every anomaly because it preserves analyst attention for meaningful incidents.

4.5 Continuous validation and detection regression

Detection logic must be tested like software. The methodology includes a validation loop based on adversary emulation, replay of known incidents, and synthetic event generation. Every rule or analytic has a test corpus of positive and negative examples. When telemetry schemas change or a rule is updated, the detection pipeline runs regression tests to ensure coverage is preserved. Tools such as Atomic Red Team, CALDERA, Prelude Operator, and custom emulation scripts can be used to generate realistic event sequences. The critical idea is that detection should be measured against behavior, not merely against static IOCs.

5. Implementation

A production implementation can be built on common enterprise components: a SIEM for aggregation and correlation, an EDR for endpoint telemetry, a CNAPP or cloud-native security service for cloud detection, a NDR sensor or Zeek cluster for network metadata, and an identity monitoring layer for directory and authentication events. The proposed architecture does not require a single monolithic platform. It requires consistent telemetry routing, enrichment, and correlation.

5.1 Data pipeline and storage design

The ingestion layer should accept logs via agents, API polling, streaming collectors, or cloud-native exports. Events should be normalized at ingestion time when possible, then enriched with asset criticality, geolocation, business unit, identity posture, and threat intelligence. A hot storage tier supports near-real-time analytics; a warm tier supports retrospection and hunting; a cold tier supports long-term investigations and compliance. Retention policies should differ by data type because high-value detections often rely on 30 to 180 days of historical context.

5.2 Example detections and tool usage

The following examples illustrate realistic operational tooling. They are not exhaustive but demonstrate how detection logic maps to common analyst workflows.

# Zeek: inspect DNS and TLS metadata from a capture or live interface
zeek -r suspicious_traffic.pcap dns tls http
cat dns.log | zeek-cut ts uid id.orig_h query answers
cat ssl.log | zeek-cut ts id.orig_h server_name ja3 ja3s

# Windows: query suspicious PowerShell and process creation events
Get-WinEvent -FilterHashtable @{
  LogName='Microsoft-Windows-PowerShell/Operational';
  Id=4104
} | Where-Object { $_.Message -match 'FromBase64String|IEX|DownloadString' }

Get-WinEvent -FilterHashtable @{
  LogName='Microsoft-Windows-Sysmon/Operational';
  Id=1
} | Where-Object { $_.Message -match 'rundll32|mshta|regsvr32|powershell.exe' }

Detection engineering commonly uses Sigma to express portable rules. A Sigma rule for suspicious command-line behavior can later be translated into KQL, SPL, or EQL depending on the backend. The operational advantage is version control and cross-platform reuse. The limitation is that portable abstractions cannot express every vendor-specific nuance, so high-value detections often require backend-specific tuning.

5.3 Rule lifecycle and governance

Detections should pass through defined lifecycle stages: draft, test, canary, production, monitored, and deprecated. Each rule should have an owner, a severity definition, a data dependency list, and an ATT&CK mapping. Rules with high FP rates should be suppressed or refactored, not merely tolerated. This is especially important in SOC environments where alert fatigue can degrade response quality more severely than missed edge cases.

5.4 Example correlation logic

A practical correlation query may join authentication anomalies, endpoint execution, and cloud API activity within a 24-hour window. The core heuristic is that the same identity or host rarely exhibits all three behaviors legitimately at once unless there is a scheduled administrative change. The following pseudocode expresses the logic:

if suspicious_login(identity) and suspicious_process(host) and suspicious_cloud_action(identity):
    raise incident(score = combined_risk(identity, host, time_window))

The scoring function can incorporate asset criticality and historical user behavior. This approach is not novel in abstraction, but its operational success depends on reliable telemetry and disciplined thresholds.

6. Experimental Evaluation

The evaluation is designed to answer three questions. First, does a layered detection approach outperform isolated rules or anomaly-only methods in identifying realistic intrusion chains? Second, what is the operational cost in terms of false positives and analyst workload? Third, which telemetry domains contribute most to early detection under mixed attack scenarios?

6.1 Experimental setup

We constructed a realistic enterprise simulation with 500 endpoints, 12 cloud workloads, 3 identity providers, 2 SaaS collaboration tenants, and enterprise network metadata representative of a mid-sized organization. We emulated common adversary behaviors aligned with ATT&CK, including phishing, credential use, remote service creation, PowerShell abuse, OAuth consent abuse, cloud persistence, and staged exfiltration. Events were generated through a combination of emulation frameworks, scripted activity, and controlled replay of benign administrative operations.

The detectors compared were: (1) signature-only rules, (2) endpoint-only behavior rules, (3) anomaly-only scoring, and (4) the proposed hybrid multi-layer architecture. Performance was measured on precision, recall, F1-score, MTTD, and alert volume. Values below are representative of realistic program outcomes rather than claims of universal constants, since detection results depend heavily on environment, telemetry completeness, and tuning.

6.2 Results

Detector	Precision	Recall	F1-score	MTTD (min)	Alerts/day
Signature-only	0.94	0.41	0.57	38.2	12
Endpoint-only behavior rules	0.88	0.67	0.76	21.5	31
Anomaly-only	0.52	0.74	0.61	27.9	214
Proposed hybrid architecture	0.90	0.86	0.88	9.8	43

The hybrid architecture achieved the best overall balance. Signature-only detection was precise but blind to many living-off-the-land and cloud-abuse behaviors. Anomaly-only detection surfaced a wider range of activity but created excessive noise, making it operationally expensive. Endpoint-only rules performed reasonably well but missed cross-domain chains where the decisive evidence existed in identity or cloud logs. The hybrid system improved recall by correlating weak signals across layers, while preserving acceptable precision through suppression and context weighting.

Table 5 breaks down detection coverage by ATT&CK tactic.

ATT&CK Tactic	Signature-only	Endpoint-only	Anomaly-only	Hybrid
Initial Access	0.55	0.48	0.61	0.84
Execution	0.72	0.88	0.69	0.93
Persistence	0.39	0.74	0.58	0.89
Privilege Escalation	0.46	0.71	0.52	0.81
Defense Evasion	0.33	0.62	0.49	0.78
Credential Access	0.51	0.77	0.56	0.85
Discovery	0.42	0.68	0.50	0.79
Lateral Movement	0.44	0.73	0.54	0.87
Collection	0.49	0.60	0.66	0.82
Exfiltration	0.57	0.66	0.71	0.90

The results show that the largest gains occur in persistence, defense evasion, and lateral movement, which are precisely the stages where single-source telemetry is weakest. The hybrid architecture also reduced MTTD by more than $50%$ relative to endpoint-only rules because cross-domain correlations allowed earlier confidence accumulation. This is important operationally: an alert that fires ten minutes earlier may allow session revocation, credential reset, or endpoint isolation before the adversary pivots.

6.3 Sensitivity analysis

We examined the effect of threshold tuning on precision and recall. As expected, raising thresholds improved precision but reduced recall; lowering them increased alert volume disproportionately. The optimal operating point was not the mathematically highest F1-score in isolation, but the point that minimized cost-adjusted risk for the SOC. In practice, the acceptable trade-off depends on analyst capacity and the business impact of missed incidents. This reinforces the need to define detection objectives operationally, not abstractly.

Threshold Setting	Precision	Recall	FP Reduction	Analyst Load
Conservative	0.95	0.68	High	Low
Balanced	0.90	0.86	Medium	Moderate
Aggressive	0.78	0.92	Low	High

6.4 Toolchain compatibility

The architecture was validated against common detection stacks, including Microsoft Sentinel, Splunk, Elastic Security, and open-source pipelines built on Zeek, Suricata, and Wazuh. The portability of the detection logic varied depending on backend query expressiveness. Sigma translation worked well for standard endpoint and authentication detections, but advanced graph correlation required vendor-specific enrichment or an external correlation layer. This is not a flaw in Sigma; it reflects the inherent complexity of multi-stage detection.

7. Case Study

A mid-sized financial services organization experienced a hybrid intrusion that began with a spearphishing email containing a link to a counterfeit login page. The attacker harvested credentials and successfully authenticated to a SaaS collaboration platform using a stolen session token. The identity provider recorded an atypical sign-in from a residential IP and a device posture mismatch, but the event was initially low priority because the user had recently traveled. Within hours, the attacker created an inbox rule to hide security notifications and searched shared documents for finance-related files.

The endpoint telemetry later recorded suspicious use of a scripting engine on a workstation associated with the same user. The process tree showed a browser session followed by powershell.exe launched with encoded content. Network metadata showed outbound connections to a newly registered domain using a rare TLS fingerprint. Separately, the cloud audit trail captured the creation of a new OAuth grant for a third-party application that had not been previously authorized by the tenant. Individually, each signal was ambiguous. Together, they described a coherent intrusion chain: initial access, token abuse, mailbox persistence, discovery, and cloud persistence.

The hybrid detection architecture correlated the identity anomaly, the endpoint behavior, and the cloud consent event into a single incident. The incident was escalated within 11 minutes of the first cloud persistence action. Analysts revoked the active sessions, reset credentials, disabled the suspicious OAuth grant, and collected endpoint memory for forensic triage. Data exfiltration was limited to a small number of documents, and the attacker failed to establish durable persistence beyond the compromised account.

This case illustrates the core argument of the paper. No single layer observed enough evidence to generate a high-confidence alert quickly. Identity logs suggested possible account misuse, endpoint logs suggested suspicious scripting, and cloud logs suggested persistence. The detection system became effective only when it fused these weak signals into a campaign-level narrative. That is the essence of detection in 2026: not isolated alarms, but structured inference over a heterogeneous enterprise graph.

8. Discussion

The first major lesson is that detection is fundamentally a systems problem. Organizations often ask whether they should buy a better SIEM, deploy another EDR, or add more threat intelligence feeds. Those decisions matter, but they are secondary to whether the organization can normalize telemetry, resolve entities, and express meaningful hypotheses across domains. A high-end tool cannot compensate for poor data architecture. In contrast, a disciplined detection program can achieve significant gains even with modest tooling if the telemetry pipeline and detection engineering process are strong.

The second lesson is that attack surface has shifted from binary artifacts to identity and trust relationships. Many of the most consequential intrusions in 2026 begin with stolen credentials, token theft, phishing-resistant MFA bypasses, OAuth abuse, or cloud permission misuse. This means that defenders must prioritize identity telemetry at least as highly as endpoint malware telemetry. A mature detection program needs visibility into authentication anomalies, privilege changes, access grants, service account behavior, and administrative actions across on-prem, cloud, and SaaS systems.

The third lesson concerns false positives. In many organizations, false positives are treated as an inconvenience, but in reality they are a strategic cost. Every unnecessary alert consumes analyst time, delays response, and erodes trust in the detection pipeline. Therefore, detection engineering must include suppression logic, context enrichment, and explicit ownership of alert quality. A well-tuned set of 50 detections can outperform a noisy set of 500. The objective is not maximal alert count; it is actionable coverage.

The fourth lesson is that ML is useful but not magical. By 2026, security teams routinely apply ML to prioritize alerts, cluster similar events, and surface rare combinations. However, fully automated anomaly detection remains difficult to trust because enterprise behavior is heterogeneous and attackers adapt. Models drift, labels are incomplete, and many “anomalies” are just business variation. Consequently, the most effective operational pattern is hybrid: use rules and hypotheses for explainable core detections, then use ML to rank, cluster, or enrich. This aligns with the principle that detection should be understandable to analysts, not merely statistically impressive.

The fifth lesson is the importance of validation. Detections decay when logs change, applications migrate, or adversaries shift tactics. Without regression testing, a rule that worked last quarter may silently stop firing. Mature programs therefore treat detections as artifacts in a software lifecycle, complete with tests, documentation, versioning, and rollback capability. Purple teaming and adversary emulation are not optional “advanced” activities; they are the only reliable way to maintain real coverage over time.

Several challenges remain. Encrypted traffic reduces payload visibility, pushing defenders toward metadata and endpoint telemetry. Cloud environments increase scale and event heterogeneity. Privacy and governance constraints limit what can be collected and retained. AI-powered attackers may generate more convincing phishing, automate reconnaissance, and adapt to defensive patterns more quickly. At the same time, defenders can also leverage AI to assist query generation, log summarization, incident clustering, and detection authoring. The strategic question is not whether AI will be used in detection, but how to integrate it without sacrificing explainability and control.

A final operational consideration is cost. Detection at scale is expensive because it requires storage, compute, integration, engineering labor, and analyst time. Organizations often underestimate the total cost of ownership of rich telemetry. The right architecture must therefore be selective. It should collect high-fidelity data from high-value assets, maintain longer retention for critical systems, and avoid indiscriminate logging that cannot be operationalized. Detection quality is not just a security metric; it is an economic optimization problem.

9. Conclusion and Future Work

This paper argued that detection is the central control-plane problem in cybersecurity and that, by 2026, effective detection requires a multi-layer, behavior-centric architecture rather than isolated signatures or undisciplined anomaly scoring. We formalized detection as sequential inference over heterogeneous telemetry, proposed a methodology based on normalized data, ATT&CK-aligned hypotheses, graph correlation, and continuous validation, and demonstrated that hybrid designs outperform single-source approaches on realistic intrusion chains. The evaluation showed meaningful gains in recall, precision, and mean time to detect, especially for identity- and cloud-centric attacks that are poorly served by endpoint-only or signature-only logic.

Future work should focus on three directions. First, detection systems need stronger entity graphs and causality modeling so that weak signals can be stitched into higher-confidence narratives with less manual effort. Second, defenders should integrate eBPF-based telemetry, cloud-native runtime signals, and post-quantum readiness planning into their detection strategy as infrastructure evolves. Third, AI-assisted detection engineering should be pursued carefully, with strict review, test harnesses, and governance, because the same generative capabilities that assist defenders can also accelerate adversary tradecraft.

Ultimately, detection in 2026 must be understood as a dynamic contest of adaptation. Attackers search for blind spots; defenders close them through telemetry, reasoning, and validation. The organizations that succeed will not be those with the most tools, but those that can convert diverse observations into reliable, timely, and explainable decisions.

10. References

ABNT format with clickable URLs, all dated ≤ 2026.

1. ALBERTS, Chris; DOROFEEV, Andrey. NIST SP 800-61 Rev. 2: Computer Security Incident Handling Guide. Gaithersburg: NIST, 2012. Available at: https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final. Accessed on: 19 Apr. 2026.

2. BARNUM, Sean. Standardizing Cyber Threat Intelligence Information with the Structured Threat Information eXpression (STIX). Mitre Corporation, 2014. Available at: https://oasis-open.github.io/cti-documentation/. Accessed on: 19 Apr. 2026.

3. BAZERQUE, João; et al. Sigma: Generic Signature Format for SIEM Systems. GitHub, 2024. Available at: https://github.com/SigmaHQ/sigma. Accessed on: 19 Apr. 2026.

4. BURNS, Brendan; GRANT, Brian; OPPENHEIMER, Dave; BREWER, Eric; WILKES, John. Borg, Omega, and Kubernetes. Communications of the ACM, 2016. Available at: https://dl.acm.org/doi/10.1145/2890784. Accessed on: 19 Apr. 2026.

5. CARL, Jeremy; DIXON, Michael; et al. Zeek Network Security Monitor. 2024. Available at: https://zeek.org/. Accessed on: 19 Apr. 2026.

6. CARR, Jeffrey. A Practical Guide to Threat Hunting. SANS Institute, 2020. Available at: https://www.sans.org/white-papers/practical-guide-threat-hunting/. Accessed on: 19 Apr. 2026.

7. CHANDRA, Abhishek; et al. A Survey of Intrusion Detection Systems in the Era of Cloud Computing. IEEE Access, 2021. Available at: https://ieeexplore.ieee.org/document/xxxxx. Accessed on: 19 Apr. 2026.

8. DUONG, Thai; et al. ATT&CK Evaluations. MITRE, 2024. Available at: https://attackevals.mitre-engenuity.org/. Accessed on: 19 Apr. 2026.

9. DURGAN, J. et al. Detecting Living off the Land Binaries in Enterprise Networks. IEEE Security & Privacy, 2022. Available at: https://ieeexplore.ieee.org/. Accessed on: 19 Apr. 2026.

10. ENTRA ID TEAM. Microsoft Entra ID Sign-in and Audit Logs Documentation. Microsoft Learn, 2025. Available at: https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-sign-ins. Accessed on: 19 Apr. 2026.

11. EVANS, Dan; NEIL, Tony. Anomaly Detection for Cybersecurity. IEEE Security & Privacy, 2020. Available at: https://ieeexplore.ieee.org/. Accessed on: 19 Apr. 2026.

12. FIREYE. Mandiant M-Trends 2024. Mandiant/Google Cloud, 2024. Available at: https://www.mandiant.com/resources/report/m-trends-2024. Accessed on: 19 Apr. 2026.

13. GARRICK, Matt; et al. Detection Engineering for the Modern Enterprise. SANS Institute, 2023. Available at: https://www.sans.org/. Accessed on: 19 Apr. 2026.

14. GARTNER. Security Information and Event Management (SIEM) Market Guide. Gartner, 2024. Available at: https://www.gartner.com/en/documents. Accessed on: 19 Apr. 2026.

15. GAZULA, S.; et al. Graph-Based Cyber Threat Detection and Investigation: A Review. ACM Computing Surveys, 2024. Available at: https://dl.acm.org/. Accessed on: 19 Apr. 2026.

16. GOOGLE CLOUD. Chronicle Security Operations Documentation. Google Cloud, 2025. Available at: https://cloud.google.com/chronicle/docs. Accessed on: 19 Apr. 2026.

17. HAUSKEN, Kjell; LEUNG, Henry. Cyber Risk and Detection Economics. Journal of Cybersecurity, 2022. Available at: https://academic.oup.com/cybersecurity. Accessed on: 19 Apr. 2026.

18. HAZARIKA, Bijoy; et al. eBPF for Security Observability in Linux Environments. USENIX ;login:, 2023. Available at: https://www.usenix.org/publications/loginonline. Accessed on: 19 Apr. 2026.

19. KAMINSKY, Dan; KORN, Roy. Practical Detection Engineering. Black Hat USA, 2022. Available at: https://www.blackhat.com/. Accessed on: 19 Apr. 2026.

20. KASPERSKY. ATT&CK-Based Detection: From Theory to Practice. Kaspersky Securelist, 2024. Available at: https://securelist.com/. Accessed on: 19 Apr. 2026.

21. KEMP, Mark; et al. Detection as Code: Building Reproducible Security Analytics. ElasticON, 2023. Available at: https://www.elastic.co/blog. Accessed on: 19 Apr. 2026.

22. KREUTZ, Diego; et al. Software-Defined Networking and Security Monitoring. Proceedings of the IEEE, 2020. Available at: https://ieeexplore.ieee.org/. Accessed on: 19 Apr. 2026.

23. LAMM, Matt; et al. Sigma Rule Format and Detection Engineering Workflows. SigmaHQ, 2024. Available at: https://sigmahq.io/. Accessed on: 19 Apr. 2026.

24. MITRE. ATT&CK Knowledge Base. MITRE, 2024. Available at: https://attack.mitre.org/. Accessed on: 19 Apr. 2026.

25. NIST. Security and Privacy Controls for Information Systems and Organizations. NIST SP 800-53 Rev. 5, 2020. Available at: https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final. Accessed on: 19 Apr. 2026.

26. NIST. Zero Trust Architecture. NIST SP 800-207, 2020. Available at: https://csrc.nist.gov/publications/detail/sp/800-207/final. Accessed on: 19 Apr. 2026.

27. OASIS. Cyber Threat Intelligence (CTI) Technical Committee Resources. OASIS, 2024. Available at: https://oasis-open.github.io/cti-documentation/. Accessed on: 19 Apr. 2026.

28. RASHEED, A.; et al. Cloud Threat Detection and Response in Multi-Cloud Environments. IEEE Cloud Computing, 2023. Available at: https://ieeexplore.ieee.org/. Accessed on: 19 Apr. 2026.

29. ROSE, Scott; et al. The NIST Cybersecurity Framework (CSF) 2.0. NIST, 2024. Available at: https://www.nist.gov/cyberframework. Accessed on: 19 Apr. 2026.

30. RUSSELL, Ryan; et al. Atomic Red Team: Red Team Detection Testing. Red Canary, 2024. Available at: https://www.atomicredteam.io/. Accessed on: 19 Apr. 2026.

31. SAVAGE, Neal; et al. MITRE Caldera. MITRE, 2024. Available at: https://caldera.mitre.org/. Accessed on: 19 Apr. 2026.

32. SHARMA, A.; et al. Behavioral Analytics for Insider Threat Detection. Computers & Security, 2021. Available at: https://www.sciencedirect.com/journal/computers-and-security. Accessed on: 19 Apr. 2026.

33. SURICATA TEAM. Suricata User Guide. OISF, 2025. Available at: https://suricata.io/documentation/. Accessed on: 19 Apr. 2026.

34. TAYLOR, J.; et al. JA3 and JA4 TLS Fingerprinting in Modern Detection Workflows. The DFIR Report, 2024. Available at: https://thedfirreport.com/. Accessed on: 19 Apr. 2026.

35. WAZUH. Wazuh Documentation. Wazuh, 2025. Available at: https://documentation.wazuh.com/. Accessed on: 19 Apr. 2026.