An Operational Framework for SOC-Integrated Attack Detection in 5G Standalone Networks

Abstract

The deployment of 5G standalone (SA) networks introduces cloud-native core architectures, service-based interfaces, and programmable radio access networks that substantially expand the mobile attack surface. Existing work has focused mainly on protocol-level vulnerabilities or isolated anomaly detection, with less attention to SOC-level monitoring, correlation, and investigation of 5G-specific threats. This paper presents a SOC-integrated, protocol-aware detection framework for 5G SA environments, combining structured telemetry ingestion, log normalization, decision-based detection logic, and analyst-oriented visualization within an Elastic-Stack-based SOC architecture. The approach is implemented on an experimental 5G SA testbed at Obuda University and evaluated using a dual-source design: controlled testbed scenarios complemented by an observational analysis of telemetry from an independent, large-scale international cyber-defense exercise whose adversarial complexity is difficult to reproduce synthetically. The evaluation exercises attack scenarios including rogue network element registration, authentication abuse, and control- and user-plane manipulation. The results indicate that embedding 5G-aware detection logic into SOC workflows supports situational awareness and structured incident investigation. A single-layer versus cross-layer ablation of the published detection rules quantifies where cross-layer correlation is strictly required for detection versus where it primarily enriches interpretation. This is extended with a limited generic-SIEM-style baseline check and a live, a priori repeated-trial sensitivity check ($N=30$, Wilson 95% CI [88.6%, 100%]). The framework offers a reproducible methodological foundation for operational 5G security monitoring and practical guidance for next-generation mobile network defense. Future work will extend controlled repeated-trial evaluation to the remaining detection rules, broaden the SIEM baseline comparison, and assess generalizability beyond Open5GS.

1. Introduction

The transition to 5G standalone (SA) architectures introduces cloud-native core functions, service-based interfaces, and programmable radio access networks. While these features enable scalability and flexibility, they also expand the attack surface and increase operational complexity. Control-plane services such as the AMF, SMF, and UPF interact through IP-based service interfaces that are susceptible to protocol abuse, signaling overload, and misconfiguration. At the radio layer, software-defined implementations lower the barrier for deploying rogue or misconfigured network elements.

The security stakes of this transition are amplified by the role 5G increasingly plays as critical infrastructure. Beyond public mobile broadband, 5G SA now underpins private and non-public networks in industrial, healthcare, energy, and defense settings, where a successful intrusion can translate directly into safety, continuity, or sovereignty consequences. At the same time, the democratization of the technology stack—open-source cores, software-defined radios, and commodity hardware—means that the same tools enabling rapid private-network deployment are also available to adversaries, lowering the cost of mounting realistic attacks. Operators of these networks are frequently enterprises or research institutions without the mature, telco-grade security operations that protect traditional carrier cores. This combination of high impact, accessible offensive tooling, and constrained defensive capability makes practical, analyst-centric detection necessary for 5G SA. Yet most existing detection research stops at the algorithmic or protocol level and offers little guidance on how such detection is operated, correlated, and investigated day to day.

Existing research has primarily addressed 5G security at the protocol or anomaly-detection level, often focusing on individual signaling interfaces or machine-learning-based detection models. However, effective protection of operational 5G infrastructures requires more than isolated detectors: it demands centralized visibility, cross-layer correlation, and analyst-facing interpretability within a security operations center (SOC).

This paper proposes a SOC-integrated, protocol-aware detection framework tailored to 5G SA environments. Rather than treating the SIEM as a passive log collector, we position the SOC as an active operational layer shaping detection design, telemetry processing, and alert contextualization. The framework combines adaptive telemetry ingestion, decision-function-based detection logic, and structured threat-to-detection mapping within a reproducible 5G testbed.

The main contributions of this paper are summarized below.

• SOC-integrated detection framework. A structured, SOC-centric detection framework for 5G SA environments that embeds protocol-aware detection logic directly into SOC workflows.
• Protocol-aware correlation architecture. A telemetry-normalization and correlation architecture for heterogeneous 5G logs, supported by an explicit correlation predicate with empirically estimated time windows where the baseline data permit such estimation (Section 3).
• Operational threat-to-detection mapping. A mapping that connects concrete 5G SA attack scenarios to observable telemetry, detection rules, coverage outcomes, and investigation pivots, evaluated on a dual-source design combining controlled testbed data and observational exercise telemetry (Section 4).
• Quantitative ablation and sensitivity evaluation. A nine-rule single-layer-versus-cross-layer ablation that identifies where cross-layer correlation changes detection or interpretation, complemented by a live, $N=30$ repeated-trial sensitivity and repeatability check for two of those rules (Section 5.2).
• Transparent evidence taxonomy. A four-class evidence taxonomy (Section 4) that distinguishes controlled repeated-trial evidence from single-instance field observations and retrospective attribution, making the evidential strength of each finding explicit.

Together, these contributions show how SOC-integrated, cross-layer detection can add operational context relative to isolated monitoring approaches. The study did not evaluate the effect on alert noise or analyst workload in a controlled setting; these limitations are discussed in Section 5.

The remainder of this paper is organized as follows. Section 2 reviews related work on 5G security, protocol-aware detection, and SOC/SIEM operationalization. Section 3 presents the SOC-integrated detection framework, including the formal model, threat model, and operational mapping. Section 4 describes the experimental testbed and validation. Section 5 discusses the findings and comparative observations, and Section 6 concludes the paper.

2. Related Work

While prior work has addressed 5G anomaly detection at the protocol level and explored NWDAF-based analytics within the 5G core, these approaches typically evaluate detection as an isolated analytical component. Similarly, SIEM integration studies often treat 5G telemetry as an additional log source within generic monitoring pipelines. In contrast, this work integrates detection logic, telemetry normalization, and analyst workflows within a unified SOC model explicitly designed for 5G environments. The contribution is therefore not merely the detection of additional attack vectors but the operationalization of 5G-specific detection in a sustainable and analyst-centric SOC framework.

2.1. 5G SA Attack Surface and Security Requirements

Several studies emphasize that the 5G core’s service-based architecture (SBA), IP-native interfaces, and virtualization introduce new security challenges compared to legacy mobile networks and call for requirements that address both protocol abuse and operational realities, including misconfiguration, scaling dynamics, and multi-domain complexity [1]. Beyond component-level vulnerabilities, higher-level frameworks also attempt to structure the threat landscape; for example, ontology-driven approaches aim to systematically capture hybrid threats and cross-domain risk in 5G environments [2]. Complementing these perspectives, research on protocol tunneling and boundary-bridging attack paths highlights how attackers may exploit architectural boundaries to reach unexpected assets or traverse trust zones in 5G deployments [3]. At the standards level, 3GPP TS 33.501 defines the baseline 5G security architecture and procedures, yet operational deployments frequently diverge from these assumptions [4]. Recent analyses of 5G control- and user-plane vulnerabilities catalog concrete attack patterns against PFCP, GTP-U, and SBA interfaces [5]. Log-based techniques have also been proposed specifically for detecting man-in-the-middle attacks on the PFCP protocol [6], a direction closely aligned with the present work, which we extend through cross-layer correlation and SOC-workflow integration. Identity-layer threats also persist: SUCI-catcher attacks demonstrate that subscriber-identity confidentiality can be undermined even under 5G encryption, motivating operator-side detection [7,8]. Together, these works motivate detection methods that operate across layers and remain robust under architectural and operational change.

2.2. Protocol-Aware and Analytics-Based Detection in 5G

A major body of work focuses on detecting anomalies in 5G control-plane signaling, often using machine learning on protocol features. NGAP has received particular attention, as anomalies near the 5GC boundary can indicate attacks against core-facing interfaces. Temporal attention-based LSTM approaches emphasize temporal dependencies and boundary behavior [9]. Hybrid feature-fusion models instead combine heterogeneous NGAP-derived features in edge-security contexts [10], while temporal graph neural networks capture structural and temporal patterns in signaling and core interactions [11]. In parallel, log-centric anomaly detection provides transferable methods for SOC telemetry; interpretable approaches using recurrent neural networks with attention demonstrate how sequence modeling helps analysts understand why an anomaly was flagged [12]. These methods, while powerful, typically assume stable feature schemas or curated datasets, whereas operational 5G environments exhibit rapidly evolving log formats, motivating SOC-integrated pipelines that preserve adaptability.

A complementary direction embeds analytics directly into the 5G architecture through the network data analytics function (NWDAF). Experimental comparisons report that statistical methods can outperform certain ML methods for volume-based DoS/DDoS detection, recommending hybrid approaches for diverse network conditions [13], while more security-centric NWDAF designs propose threat detection and mitigation modules that leverage SBA visibility and analytics feedback loops [14]. These works reinforce that detection should be integrated with 5G-native observability rather than isolated; however, NWDAF-centric approaches do not directly address SOC workflows such as alert triage, cross-source correlation, and analyst-facing interpretability, which are critical in operational defense.

2.3. SOC/SIEM Operationalization and 5G Experimentation

Security monitoring is traditionally operationalized through SOC and SIEM platforms, where research emphasizes correlation, continuous monitoring, and operational response as the backbone of enterprise defense [15]. Open-source SIEM solutions have been studied extensively as deployable alternatives. Surveys and deployment-oriented works discuss Wazuh-based architectures and selection criteria under resource constraints [16]. ELK-based implementations integrating Wazuh combine monitoring, alerting, and integrity monitoring into a coherent workflow [17], and broader frameworks propose open-source single-pane security management integrating ingestion, analytics, and dashboards [18]. Recent work further explores augmenting SOC operations with retrieval-augmented generation (RAG) copilots for improved event response and knowledge access [19]; such approaches still rely on high-quality telemetry normalization and context-rich event data, which is especially challenging with heterogeneous, evolving 5G logs. More broadly, machine-learning-based anomaly-detection surveys for NFV environments map the design space of detectors for virtualized infrastructures on which 5G cores are deployed [20].

Realistic experimentation underpins this operational perspective. Virtual end-to-end 5G testbeds support repeatable validation of detection methods [21], and monitoring-focused studies examine secure, low-footprint Open5GS deployments emphasizing operational observability and practical instrumentation [22]. To enable comparable evaluation, datasets targeting 5G control- and data-plane security and resource-management use cases have been released [23], while survey works synthesize machine learning and transfer learning approaches for IDS in 5G and beyond, mapping challenges such as concept drift, class imbalance, and deployment constraints [24].

2.4. Scenario-Based and Operational SOC Evaluation

Scenario-based evaluation has a long tradition in intrusion detection research. The DARPA 1998 and 1999 IDS evaluations, coordinated by MIT Lincoln Laboratory, introduced repeatable testbed-based assessment using simulated background traffic, labeled attack sessions, host and network audit data, and both offline and real-time evaluation modes. The 1999 evaluation included three weeks of training data, two weeks of test data, and more than 200 instances of 58 attack types, while explicitly measuring detection and false-alarm behavior [25]. These evaluations demonstrated the importance of realistic background traffic, timestamped attack truth, and false-alarm characterization but also showed that detection systems performed poorly on new, stealthy, and insufficiently instrumented attacks [26].

Subsequent extensions, including the Lincoln Adaptable Real-time Information Assurance Testbed (LARIAT), moved beyond isolated atomic attacks toward configurable real-time intrusion detection and correlation experiments. Scenario-specific datasets were introduced to represent multi-component attack sequences rather than single attack events, thereby anticipating later cyber range and SOC-oriented evaluation practices [27]. This shift is particularly relevant for 5G environments, where attacks often unfold across radio access, core signaling, user-plane tunneling, administrative interfaces, and telemetry infrastructure.

Operational SOC evaluation further broadens the assessment focus from classification accuracy to analyst-facing effectiveness. In SOC settings, detection quality is affected not only by true positives and false positives but also by alert latency, alert volume, triage effort, contextual enrichment, investigation pivots, and the ability to correlate distributed evidence across systems. Metrics such as mean time to detect (MTTD), mean time to respond (MTTR), false positive rate, and alert coverage are commonly used to characterize SOC performance and analyst workload. In addition, excessive false positives directly contribute to alert fatigue and reduce operational effectiveness. The present study reports detection latency (an MTTD-type measure, $L_d$ in Section 3) and false positive behavior in context. Response-time (MTTR) measurement requires observing analyst remediation actions; this was outside the scope of the single-instance exercise reported here and is noted among the future work items in Section 5.

The present work follows this scenario-based evaluation lineage but adapts it to 5G-specific operational monitoring. Instead of evaluating a detector only against an offline dataset, the proposed methodology evaluates whether bounded attack scenario instances produce observable, correlated, and investigable telemetry footprints inside a SOC. This motivates the use of attack scenario instances, detection latency, false positive characterization, coverage assessment, and analyst investigation pivots as evaluation dimensions.

2.5. Summary and Research Gap

Overall, prior work provides detailed analysis of 5G-specific threats and security requirements [1,2], protocol-aware anomaly detection methods for control-plane traffic [9,10,11], architecture-integrated analytics via NWDAF [13,14], and SOC/SIEM operational frameworks and open-source SOC implementations [16,17,18]. However, a persistent gap remains at the intersection of 5G-specific detection semantics and SOC-centric operationalization: many detection proposals are evaluated as isolated models or component-centric analytics, while real-world defense requires centralized visibility, adaptable telemetry processing, and analyst-facing workflows. This paper addresses that gap by embedding 5G-aware detection logic into a SOC architecture designed for heterogeneous 5G telemetry, emphasizing maintainable parsing, context enrichment, operationally actionable alerting, and dashboard-supported investigation.

Table 1 situates the contribution against the closest lines of prior work. NWDAF-based analytics [13,14] embed detection into the 5G architecture but do not expose SOC workflows such as triage, cross-source correlation, and analyst pivots. Open-source SIEM integrations [16,17,18] operationalize monitoring but treat 5G telemetry largely as a generic log source, lacking protocol-aware detection semantics. Protocol-level ML detectors [9,10,11] achieve strong classification on curated NGAP features but are evaluated in isolation from operational context. In contrast, the present work jointly delivers protocol-aware detection, cross-layer correlation over heterogeneous and evolving 5G logs, analyst-facing investigation support, and a reproducible SOC-embedded evaluation.

Table 1. Author-assessed qualitative positioning of this work against the closest prior art across operational-defense dimensions, based on a reading of the cited publications rather than a reproduced empirical comparison. F: fully addressed; P: partially addressed; –: not addressed.

Dimension	NWDAF [13,14]	ELK/Wazuh [16,17,18]	Open5GS Mon. [22]	ML IDS [9,10,11]	This Work
5G protocol-aware detection semantics (NGAP/PFCP/GTP-U)	P	–	–	F	F
Cross-layer correlation (RAN↔core↔user-plane↔admin)	–	P	–	–	F
Adaptivity to evolving/unstructured logs (runtime fields)	–	P	P	–	F
Analyst-facing workflow and investigation pivots	–	P	–	–	F
Operational metrics (latency, FP-in-context, coverage)	P	P	P	P	F
SOC-embedded (not a standalone detector)	P	F	–	–	F
Reproducible 5G SA testbed with released artifacts	–	–	P	P	P *
Empirical baseline comparison (generic SIEM vs. proposed)	–	–	–	–	P *

* Detection rules and Grok-based ingest pipeline patterns are released alongside this submission (see Data Availability Statement); a self-generated benign baseline telemetry capture is now available (Section 5), while a self-generated attack-scenario dataset and the controlled generic SIEM baseline remain in progress.

3. SOC-Integrated Detection Framework for 5G SA Networks

The proposed framework is presented as a single methodological chain rather than as separate modeling, threat-taxonomy, and SOC-engineering artifacts. The chain starts from the observable 5G attack surface, formalizes attack scenario instances as time-bounded units of analysis, and then translates the expected observables into SOC telemetry, correlation logic, and analyst-facing decisions. This organization is intended to keep the formal model, the threat model, and the operational SOC implementation tightly connected: each formal element introduced below is later used to structure either the detection mapping or the experimental validation.

3.1. Observable Attack Surface and Threat Assumptions

The framework assumes that only attacks leaving traces in logs, metrics, protocol events, or management-plane activity can be operationalized in a SOC. Accordingly, the threat model is bounded by observability: radio, core, user-plane, service-based, inter-network, and administrative domains are considered where they produce evidence that can be collected, normalized, correlated, and interpreted by analysts. We model the 5G attack surface as a set of operationally observable domains:

$$S=\{S_{RAN},S_{CORE},S_{UPF},S_{SBA},S_{SEPP},S_{ADMIN}\}$$

(1)

where $S_{RAN}$ denotes radio access and gNodeB-facing behavior, $S_{CORE}$ core network functions, $S_{UPF}$ user-plane forwarding and tunneling, $S_{SBA}$ service-based interfaces, $S_{SEPP}$ inter-network and roaming-related interfaces, and $S_{ADMIN}$ administrative services and management interfaces.

An attacker capability profile is represented as

$$C=⟨c_{radio},c_{core},c_{admin},c_{interdomain}⟩$$

(2)

where each element denotes whether the adversary has radio-layer, core-network, administrative, or inter-domain access capability. A threat instance is then expressed as

$$\tau =⟨s,c,a,i,o⟩$$

(3)

where $s\in S$ is the affected attack surface, c is the required capability profile, a is the adversarial action, i is the expected operational impact, and o is the SOC-observable evidence produced by the action.

The threat model assumes an adversary with varying levels of capability, ranging from external attackers with access to SDR equipment to insiders or compromised components with partial access to core network interfaces. The environment under consideration is a 5G SA deployment using open-source components, which closely resembles emerging private and non-public network scenarios, as well as experimental and academic deployments.

The model reflects the layered architecture of 5G networks, encompassing the radio access network, the core network control plane, the user plane, administrative interfaces, and inter-network interfaces. While physical-layer attacks such as wideband jamming are acknowledged, the primary focus is placed on attacks that interact with higher-layer protocols and network functions. This focus is intentional: such attacks are more likely to be observable through SOC telemetry and represent realistic threats in operational 5G environments where physical-layer monitoring may be limited.

The main attack categories considered in this work are data leakage and unauthorized access, rogue network element registration, protocol manipulation and control-plane abuse, denial-of-service against core components, user-plane manipulation, inter-network SEPP-related anomalies, and telemetry disruption. These scenarios share a common characteristic: they produce observable effects within operational telemetry, such as abnormal signaling patterns, unexpected network element behavior, unusual administrative actions, or degradation of expected heartbeats and metrics. Table 2 summarizes the structured threat model. It should be read as the operational scope of the framework rather than as an exhaustive 5G threat catalog.

Table 2. Structured threat model for 5G Standalone environments.

Attack Scenario	Target Component	Attack Nature	Access Type	Impact
Enumeration of existing users via WebUI	Administrative interface (WebUI)	Data exfiltration	Direct	Medium
Forced deregistration of valid UEs (direct access)	User equipment (UE)	Denial-of-service	Direct	High
Forced deregistration of valid UEs (pivoted access)	User equipment (UE)	Denial-of-service	Pivoted	High
Compromise of core network servers (AMF/SMF/UPF)	Core network functions	Unauthorized access/data exfiltration	Direct	High
User-plane traffic diversion at UPF	User-plane function (UPF)	Protocol manipulation	Direct	High
AMF process disruption	Access and mobility management (AMF)	Denial-of-service	Direct	Critical
Data deletion via WebUI or database access	Core/administrative systems	Sabotage/data exfiltration	Direct	Critical
Rogue UE registration	User equipment (UE)	Rogue device registration	Direct	Medium
Rogue gNodeB registration	Radio access network (gNB)	Rogue base station deployment	Direct	Critical
Rogue SEPP registration	Inter-network security proxy (SEPP)	Rogue network component registration	Direct	Critical
UE registration through illegitimate SEPP	User equipment (UE)	Pivoted rogue registration	Pivoted	Critical

3.2. Attack Scenario Instances and Detection Decisions

The structured threat categories in Table 2 are operationalized through attack scenario instances. An ASI connects adversarial actions to expected telemetry and therefore serves as the bridge between abstract threat categories and measurable SOC evidence. For scenario-based evaluation, we define an attack scenario instance (ASI) as

$$ASI=⟨A,T,I,O⟩$$

(4)

where A denotes the sequence of attacker actions; T represents temporal parameters such as duration, rate, and timing; I denotes the initial network state prior to execution; and O represents the set of expected observable telemetry indicators within the SOC.

ASIs provide a reproducible unit of analysis for relating threat categories to observable SOC evidence. Where repeated execution is feasible, ASIs may be re-run under controlled variation of T; however, the core objective of this study is to validate that each category produces distinct, investigable telemetry footprints when observed through the SOC.

To make the formal model operationally concrete, Table 3 instantiates the threat-instance tuple $\tau =⟨s,c,a,i,o⟩$ for the representative scenarios exercised in this study, linking each affected attack surface $s\in S$ and required capability profile c to the adversarial action a, expected impact i, and SOC-observable evidence o. This mapping serves as the connective tissue between the formal model (Section 3), the detection design (Table 4), and the coverage assessment presented later in this article.

Table 3. Instantiation of the threat-instance tuple $\tau =⟨s,c,a,i,o⟩$ for representative scenarios. Capabilities c use the profile $⟨c_{radio},c_{core},c_{admin},c_{interdomain}⟩$.

Scenario	Surface s	Capability c	Action a	Impact i	Observable o
Rogue gNB registration	$S_{RAN}$	radio	Register unknown gNB via NGAP	Critical	Unknown source IP + unseen RAN_ID; short session lifetime
Rogue UE/GTP-U injection	$S_{RAN}$, $S_{UPF}$	radio	Register outsider UE, then spoof GTP-U source	High	Unknown SUCI; UPF source-spoofing DROPs on matching TEID
Core DoS (PFCP flooding)	$S_{UPF}$	core	Flood PFCP/exhaust sessions	Critical	PFCP rate spike; missing UPF heartbeats
AMF heartbeat loss/cascade	$S_{CORE}$, $S_{SBA}$	core	Disrupt AMF/trigger SCP retries	Critical	Missing heartbeat; SCP retry storm; stale NRF state
DB credential tampering	$S_{ADMIN}$	admin	Modify subscriber records via MongoDB	Critical	Admin session; downstream UDR/PCF auth failures (retrospective)
SEPP N32c failure	$S_{SEPP}$	interdomain	Disrupt N32c handshake	High	N32c timer expiration; repeated retry loop
Rogue SEPP registration	$S_{SEPP}$	interdomain	Register illegitimate SEPP	Critical	Anomalous SEPP connection (unexercised; coverage gap)
SSH brute force (precursor)	$S_{ADMIN}$	admin	Repeated root login attempts across NFs	High	Aggregated auth failures across network functions

Table 4. Threat-to-detection mapping.

Detection Rule	Attack Category	Primary Component	Detection Type
Unknown or failed authentication detected	Access and authentication abuse	Subscriber/identity layer	Early
Multiple authentication failures (WebUI)	Access and authentication abuse	Administrative interface	Early
Successful API login from anomalous source	Access and authentication abuse	API/admin services	Reactive
Unauthorized IMSI/SUPI tracking attempt	Identity misuse	Subscriber management	Early
Connection refused to unknown gNB	RAN-based threats	gNB/AMF	Early
Unexpected gNB connection attempt	RAN-based threats	gNB/AMF	Early
New outsider UE session detected	Rogue device activity	gNB/UE	Early
Suspicious UE session removal	Rogue device activity	gNB/UE	Reactive
gNB or connection failure anomalies	RAN instability/abuse	gNB connectivity	Reactive
PFCP flooding (UPF DoS)	Core denial-of-service	UPF	Early
Heartbeat-based UPF DoS detection	Core denial-of-service	UPF	Early
Missing UPF heartbeat	Core denial-of-service	UPF	Reactive
Remote PFCP restarts/no UPF available	Core denial-of-service	UPF/SMF	Reactive
Failed SBI messages/NRF discovery issues	Internal SBI anomalies	SMF/NRF	Reactive
Duplicate remote requests	SBI signaling abuse	SMF/SBA	Early
UE session releases/policy removals	Internal control-plane issues	SMF/Policy	Reactive
Possible database dump detected	Insider/data exfiltration	Database layer	Early
Failed lateral movement in WebUI	Insider/privilege abuse	Administrative interface	Early
SEPP connection anomalies	Roaming/inter-network risk	SEPP	Reactive
GTP & PFCP connection issues	User-plane instability	UPF/data path	Reactive

Detection mechanisms are modeled as decision functions operating over time-bounded telemetry windows:

$$D:E_{(t_0,t_1)}\to \{0,1\}$$

(5)

where $E_{(t_0,t_1)}$ denotes the set of observable 5G telemetry within a time window, and $D=1$ indicates alert generation. Threshold-based rules can be expressed as

$$D\left(E\left(t\right)\right)=\left\{\begin{array}{cc}1\hfill & \mathrm{if} f\left(E\right(t\left)\right)>\theta \hfill \\ 0\hfill & \mathrm{otherwise}\hfill \end{array}\right.$$

(6)

This abstraction unifies protocol-aware rule logic and rate-based anomaly conditions under a single operational decision model.

For operational monitoring, responsiveness is treated as a first-class property. Detection latency is defined relative to observable telemetry:

$$L_d=t_{alert}-t_{first\text{\_}observable}$$

(7)

where $t_{first\text{\_}observable}$ is the timestamp of the first attack-attributable telemetry event available to the SOC, and $t_{alert}$ is the timestamp at which an alert is generated. This definition reflects SOC visibility constraints and supports reproducible measurement when timestamps are available.

False positives are framed operationally as analyst-impacting events rather than purely statistical misclassifications. A false positive is defined as an alert generated during benign operation or controlled misconfiguration that requires analyst dismissal. Accordingly, false positive behavior is characterized through benign baseline windows and maintenance-like perturbations such as NF restarts, heartbeat delays, time drift, and telemetry degradation.

The decision-function model above leaves the correlation step—when two individually valid alerts should be merged into one incident—implicit. We make this explicit. An alert is represented as $a=⟨r,t,K,\lambda ⟩$, where r is the rule identifier, t the timestamp, $K\left(a\right)$ the set of entity keys extracted from the alert (subscriber identifier, TEID, source IP, RAN_ID), and $\lambda \left(a\right)$ its plane (RAN/CP/UP/ADMIN/INFRA). Two alerts correlate if

$$\mathrm{Corr}(a_i,a_j)=1\iff K\left(a_i\right)\cap K\left(a_j\right)\ne Ø \wedge |t_i-t_j|\le \Delta$$

(8)

and an incident is a connected component of the resulting graph. $\Delta$ itself was estimated, where the data permitted, from the 29.3-h benign baseline described in Section 4. We calculated 2138 nearest-neighbor gaps between benign events that shared a subscriber identifier across different control-plane network functions. The 99th percentile was $12.5$ s. Because the baseline contained only three active subscribers, we treat this value as an order-of-magnitude estimate rather than a precise population percentile. A corresponding cross-domain value (admin plane ↔ 5G core) could not be estimated the same way: the collected admin-plane baseline log contains no subscriber-identifiable events at all, meaning the two planes never share a joinable key in this dataset. This is the empirical justification for why the database-admin-anomaly rule (Table 4) instead uses a fixed temporal corroboration window rather than an identifier join for its cross-source evidence.

Applying this predicate to the two multi-source attack chains documented in Section 4 gives a concrete, checked instantiation rather than a purely notional one. For the rogue-UE/GTP-U-injection chain (C-2, Table 5), the registration and injection alerts share a TEID/subscriber linkage and are 4.9 s apart, independently reproducing this study’s own $L_d=5$ s figure for that case and correctly merging into one incident under any plausible $\Delta$. For the SSH-brute-force/rogue-gNB chain (C-1 and its precursor), the rogue-gNB alert and the co-occurring outsider-UE-session alert (0–2 s apart, same registration event) correctly merge. The brute-force alert, however, is separated from the rogue-gNB alert by approximately 5 h14 m despite sharing the same source IP; this gap exceeds any $\Delta$ derived here by one to three orders of magnitude. We accordingly describe the brute-force and rogue-gNB events as two temporally distinct alerts from the same threat actor rather than as one tightly-coupled correlated incident, consistent with what a formally $\Delta$-bounded correlation engine would report.

Table 5. Detection outcomes and latency observations.

Scenario	# Alerts	FP/FP/h	${\mathit{L}}_{\mathit{d}}$	Correlated Sources	Analyst Action
Attack events—25–26 March 2026
Critical: Rogue gNB + UE reg. (C-1)	2	0	Immediate	amf/journal	RAN isolation and identifier audit
Critical: GTP-U injection (C-2)	1+154 a	0	5 s	amf/journal; upf/journal	TEID termination and UPF strict-IP-check verification
High: SSH brute force (C-1 precursor)	1 b	0	∼5 min c	*/auth.log (wildcard: any NF; 13 NFs)	Source blocking and successful-login verification
High: MongoDB admin session (H-1)	1	0	Retro. d	MongoDB oplog; UDR/PCF auth	Credential rotation and subscriber integrity audit
High: Rogue UE registrations (H-3)	4	0	Immediate	amf/journal	Rogue identity de-registration and cloned-SIM check
High: SSH to SEPP from IPX (H-2)	1	0	Immediate	sepp/auth.log; sepp/journal	SEPP access-control verification
Medium: AMF heartbeat loss (M-2)	1	0	∼30 s	amf/journal; SCP logs	SCP and NRF state verification
Medium: SEPP N32c failure (M-3)	1 (sust.)	0	Immediate	sepp/journal	Peer SEPP routing and TLS capability verification
False positive test conditions
Baseline: Benign traffic (extended, 29.3 h)	0–3 e	0.0–0.10/h	n/a	amf/journal; upf/journal; gnb/journal	None—clean 29.3-h window; sole trigger is a monitoring-start artifact
Test: NF restart, SEPP cascade	∼111 ev.	∼1330/h burst; ∼327/h sust.	Immediate	sepp, amf, upf journals	Maintenance correlation and alert dismissal
Test: Time sync drift	≥3	≥1.5/h	∼2 h	*/syslog.1	NTP verification and timestamp correction
Test: Telemetry degradation	≥8	≥38/h	Immediate	*/kern.log	Agent-stop investigation and telemetry gap assessment

^a One policy alert for rogue UE registration plus 154 rate-based UPF DROP events counted separately. ^b Single aggregated alert fires when the rate threshold is crossed. ^c Rate-based detection requires an accumulation window. ^d Detected retrospectively: MongoDB administrative activity was correlated with downstream UDR/PCF authentication failures. ^e Range reflects two subscriber-index initialization assumptions for the sole rule that fired (outsider-ue-session); see Section 5.

3.3. Operational Mapping to SOC Telemetry and Analyst Workflow

The detection layer is designed as an operational translation of the model above. Detections are not treated as isolated analytical rules; each rule is linked to an attack objective, affected 5G component, telemetry source, correlation requirement, and analyst interpretation. This structure makes coverage gaps explicit and prevents the framework from becoming a loose collection of alerts.

The core design principle is that detections are not treated as isolated analytical rules but as SOC-integrated operational capabilities that leverage centralized telemetry, contextual enrichment, and cross-layer correlation. Each detection is defined not only by the attack it targets but also by the data sources it consumes, the processing pipeline it relies on, and the operational context in which alerts are evaluated.

Detection rules are designed according to four principles. First, detections must be protocol-aware, incorporating knowledge of 5G signaling semantics rather than relying solely on generic anomaly indicators. Second, they must be context-enriched, correlating subscriber identifiers, network function roles, temporal patterns, and component health indicators. Third, detections must be operationally actionable, producing alerts that can be interpreted and investigated within SOC workflows. Finally, detection logic must be adaptable, accommodating evolving log formats and deployment configurations without frequent reengineering.

Protocol-aware rules capture semantic violations, such as source address mismatch in a GTP-U tunnel, unknown gNodeB identifiers, repeated authentication failures, or missing heartbeats. Rate-based rules detect abnormal event accumulation within time windows, such as PFCP flooding, brute-force authentication attempts, or restart storms. Reactive rules identify absence or degradation of expected behavior, such as missing heartbeat messages, unreachable telemetry agents, or interrupted SEPP connections. These rule types are evaluated together in the SOC so that alerts can be correlated across control-plane, user-plane, administrative, and monitoring layers.

Each detection is explicitly mapped to a threat category, primary component, and detection type. This mapping ensures that coverage gaps can be identified and that detection priorities align with operational risk. By structuring detections around attack objectives and affected components, the SOC is designed to provide consistent alerting semantics and reduce analyst fatigue caused by fragmented or redundant alerts; this is a design objective rather than a measured outcome, as no controlled analyst-fatigue study was conducted. Figure 1 presents this mapping as a correlation graph, making explicit the many-to-many relationships between threat categories, detection rules, and the network functions on which evidence is observed; Table 4 provides the detailed per-rule breakdown.

Figure 1. Threat-to-detection mapping. Each threat category (Table 2, left) is traced to the SOC detection categories it triggers (Table 4, right). Ribbon color encodes source threat severity (Critical/High). The individual threat and detection categories are not claimed as novel; the proposed contribution is the operational many-to-many mapping and cross-layer SOC correlation represented by the ribbons, which a purely tabular representation cannot convey.

The detection methodology thus forms a coherent layer within the SOC architecture, bridging raw telemetry and operational response. Rather than attempting to eliminate all threats at the detection layer, the approach emphasizes early warning, contextual awareness, and support for rapid investigation.

4. Experimental Validation

This section evaluates the proposed framework using a dual-source design, detailed in Section 4.1. The evaluation follows the same chain introduced in Section 3: attack scenario instances produce telemetry footprints that are collected through the SOC pipeline, and the resulting alerts are assessed in terms of responsiveness, interpretability, benign anomaly behavior, and coverage. The purpose is not to claim statistical completeness over repeated trials but to demonstrate that the proposed framework produces actionable, protocol-aware SOC evidence across representative 5G attack categories, including under realistic, high-complexity adversarial conditions.

4.1. Study Design and Data Provenance

The evaluation draws on two complementary data sources, chosen deliberately to balance reproducibility against ecological validity.

First, a controlled testbed hosted at Obuda University (Section 4.2) reproduces representative attack scenarios end-to-end, so that the detection logic, ingest pipeline, and dashboards can be exercised and released as reusable artifacts. The testbed is fully under the authors’ control and reproducible but intentionally modest in scale and adversarial diversity.

Second, and central to the realism of this study, the same SOC instance and detection methodology were deployed in an independent, large-scale international cyber-defense exercise. Importantly, the two 5G SA environments share the same (or a closely similar) technological foundation—an Open5GS-based core with equivalent telemetry sources—and differ primarily in scale and complexity, the exercise environment being substantially larger. The framework was therefore exercised as a single, consistent system across both settings rather than re-implemented per environment. During the exercise, the adversarial actions were carried out by third-party red-team participants rather than by the authors, yielding multi-actor, high-complexity attack behavior against a full 5G SA deployment at a scale and diversity that cannot be reproduced synthetically on the local testbed. Because it is a one-time, externally orchestrated event, the resulting dataset is observational. It cannot be replayed under controlled variation, and the authors did not define its ground truth in advance. Attack attribution was reconstructed post hoc from correlated telemetry. The exercise’s participation terms also prohibit redistribution of the raw telemetry (see the Data Availability Statement).

Ground Truth and Attack Attribution Methodology

The exercise-derived telemetry was not pre-labeled, and its ground truth was not defined in advance by the authors. Event attribution was therefore reconstructed retrospectively, through a structured, multi-signal correlation process rather than through prior knowledge of attacker identity or intent. Specifically, an event was attributed to adversarial activity when it satisfied at least one of the following, non mutually exclusive criteria:

• Inventory inconsistency. The source host, IP address, or radio-access identifier (e.g., RAN_ID) does not correspond to any entry in the deployment’s configuration-managed inventory, ruling out legitimate infrastructure as the origin. This criterion drove the attribution of the rogue gNodeB scenario in Table 3, where the connecting IP and RAN_ID had no matching inventory record.
• Temporal–causal correlation. A sequence of protocol-level events exhibits a timing relationship inconsistent with benign operation—for example, a GTP-U source-spoofing attempt beginning within seconds of an unauthorized UE registration that supplied the corresponding tunnel identifier (TEID), as observed in the rogue UE/GTP-U injection scenario.
• Identifier-pattern anomaly. Subscriber identifiers (IMSI/SUCI) associated with an event follow a sequential or otherwise structurally implausible pattern inconsistent with legitimate subscriber provisioning.
• Cross-vector corroboration. Multiple, independently observable attack vectors originate from the same source within a bounded time window—for instance, host-level SSH authentication abuse and RAN-level rogue-gNodeB signaling sharing a common source IP—increasing confidence that the activity is coordinated rather than coincidental.

This attribution process was applied consistently across the exercise telemetry and is documented per event alongside the underlying log excerpts in the supporting technical analysis. We note this as a limitation directly tied to the observational nature of the exercise data (Section 5): this ground truth is necessarily reconstructed post hoc rather than pre-registered. This contrasts with the controlled testbed experiments, where ground truth is known a priori by construction. Some findings in the coverage matrix presented later in this section are accordingly marked as partial coverage precisely where attribution required this retrospective, multi-signal correlation rather than a single unambiguous indicator. One example is the database credential-tampering scenario, attributed via cross-referencing an administrative MongoDB session with downstream UDR/PCF authentication failures rather than via a single conclusive event.

This design shapes what the evaluation can and cannot claim. Because the same SOC and detection logic were deployed in both settings, the controlled testbed serves as a reproducible, small-scale instance of the very system observed at scale during the exercise, tightening the link between the released artifacts and the field observations. Rather than reporting repeated-trial statistics over author-orchestrated attacks, we treat each exercise scenario as a field observation and assess whether it produced distinct, correlated, and investigable SOC footprints. The accompanying generic SIEM comparison (Section 5) is accordingly an interpretive analysis of the same telemetry rather than a controlled benchmark. Reproducibility is claimed for the methodology and released artifacts (detection rules, ingest and runtime-field pipelines, and dashboards), not for the exercise dataset; a controlled, self-generated replication on the testbed is planned to complement these observations (Section 5). The corresponding threats to validity are discussed explicitly in Section 5.

4.2. Testbed and Telemetry Pipeline

The experimental platform and the SOC pipeline are presented together because the framework depends on their interaction: the testbed generates 5G-specific behavior, while the SOC pipeline turns that behavior into searchable, correlated, and analyst-visible evidence.

The experimental platform, summarized in Figure 2, is built around a fully functional 5G standalone network deployed using the Open5GS core network implementation. The core network includes the standard 5G network functions defined by 3GPP, such as the access and mobility management function (AMF), session management function (SMF), user plane function (UPF), unified data management (UDM), network repository function (NRF), and policy control function (PCF). These components communicate over service-based interfaces and control-plane protocols representative of modern 5G deployments.

Figure 2. Experimental 5G SA testbed architecture, layered by trust zone (RAN/UE, core control plane, user plane, administrative interface, inter-network). Numbered pins mark where each threat scenario of Table 2 primarily targets the topology, colored by impact tier. The proposed SOC contribution is an external telemetry, correlation, and analyst-dashboard layer that observes the monitored, telemetry-producing components shown later in this article. It is therefore not pinned separately on this diagram as a discrete topology node. The data network and the roaming partner’s peer SEPP are outside the authors’ instrumentation and are not part of this monitored scope.

Radio access is provided through software-defined radio-based gNodeB implementations, enabling fine-grained control over radio behavior and signaling. This approach allows the environment to emulate both legitimate base stations and malicious or misconfigured radio elements, which is essential for studying attack scenarios such as rogue gNodeB registration, IMSI catching, and signaling manipulation. User equipment in the testbed consists of a combination of programmable SIM cards and commercial 5G-capable devices. This heterogeneous UE population ensures realistic authentication, mobility, and session management behavior while allowing controlled manipulation of subscriber identities and signaling flows during attack simulations. The entire environment is deployed in an isolated laboratory setting hosted at Obuda University, ensuring reproducibility and preventing unintended interference with external networks.

To monitor and analyze the experimental 5G environment, a dedicated SOC architecture was designed with emphasis on adaptability, protocol awareness, and operational usability. Unlike traditional SOC platforms designed primarily for enterprise IT environments, a 5G-oriented SOC must handle heterogeneous log formats, rapidly evolving protocol behavior, and tight temporal relationships between distributed network functions.

The SOC architecture is built on the Elastic Stack, selected due to its widespread adoption in industrial and academic contexts, its scalability, and its support for analytics and visualization. While open-source alternatives were initially considered, Elasticsearch was selected to provide a compact and unified environment for handling different log sources, generating alerts, and visually displaying events and metrics.

Log collection is performed using Elastic Agents managed through centralized Fleet policies. Agents are deployed on 5G core network components and supporting services, allowing consistent and centrally controlled data collection. Agent policies define which log sources are collected, how preprocessing is applied, and how data is forwarded into the SOC pipeline. This centralized management model is particularly important in 5G environments, where network functions are frequently containerized, scaled dynamically, or redeployed.

A major challenge in monitoring 5G core networks arises from the non-standardized and evolving nature of Open5GS log formats. Different modules generate logs with module-specific structures, and new fields may appear as software versions evolve or new features are enabled. Static parsing approaches are insufficient in such environments, as they require frequent pipeline modifications and reindexing.

To address this challenge, a custom ingest pipeline was developed to perform initial log structuring while preserving flexibility. The pipeline uses Grok-based pattern matching to extract core fields such as timestamps, module identifiers, event types, and subscriber-related information. This preprocessing step ensures that essential attributes are consistently indexed and searchable, enabling baseline filtering and correlation across components.

Beyond ingest-time processing, the SOC relies on runtime fields to handle dynamic or previously unknown log attributes. Runtime fields allow additional fields to be derived at query time from raw log content using regular expressions or scripting logic, without requiring changes to the underlying index structure. By combining structured ingest pipelines with runtime field extraction, the SOC achieves a balance between performance, adaptability, and long-term maintainability.

In addition to log data, performance and availability metrics are collected using Prometheus integrations. Metrics exposed by Open5GS components, such as registration rates, session counts, heartbeat messages, and resource utilization, provide complementary visibility into the operational state of the network. Integrating metrics with log data enables cross-domain correlation, for example, linking spikes in control-plane errors to changes in component health or resource exhaustion.

4.3. Scenario Execution and Detection Behavior

Each attack scenario was analyzed as a structured ASI: those reproducible on the local testbed were executed by the authors, whereas the higher-complexity scenarios were observed as they unfolded during the international cyber-defense exercise (Section 4.1). For each scenario, the expected observable indicators were compared against the actual telemetry collected by the SOC. The following observations therefore describe not only whether an alert was produced but also whether the surrounding telemetry enabled a meaningful investigation path.

The implemented detection logic demonstrated consistent behavioral responsiveness across the defined threat categories. Authentication-related abuse, including repeated failed registrations and unauthorized identifier usage, produced observable deviations in signaling outcomes. These events were rapidly surfaced within the SOC, supported by contextual enrichment linking identifiers, access points, and temporal patterns.

Rogue network element scenarios, such as unauthorized gNodeB connection attempts and outsider UE sessions, generated distinctive signaling traces. A representative instance involved a rogue gNodeB at 10.5.12.254 with RAN_ID 74565, an address absent from the network inventory. The rogue gNodeB established an NGAP connection and registered subscriber imsi-999052687654023 through a compressed InitialUEMessage → Service Accept → UEContextReleaseRequest sequence spanning 45 s. The combination of an unknown source IP, a previously unseen RAN identifier, and a session lifetime inconsistent with legitimate handover behavior produced a distinguishable SOC indicator that triggered the unexpected-gNB-connection and outsider-UE-session detection rules.

Control-plane manipulation scenarios exhibited more nuanced characteristics. Sustained PFCP signaling anomalies and abnormal heartbeat behavior produced observable divergence from baseline component interactions. In contrast, short-lived or low-intensity deviations occasionally resembled benign retransmission behavior. Cross-correlation with performance metrics and component health indicators was observed to be important in differentiating malicious interference from transient operational instability in these scenarios.

A clear illustration of cross-layer attack structure was observed when a rogue UE registration event—establishing GTP tunnel TEID 0x9031—was followed within five seconds by 154 GTP-U source IP spoofing DROP events on the UPF, with the spoofed source address 192.168.5.2 differing from the UE’s allocated address 100.99.5.3. Neither the control-plane registration event nor the user-plane DROP events alone constituted a conclusive indicator; their temporal correlation within the SOC reconstructed the attack chain as rogue UE registration followed by GTP-U injection. Figure 3 summarizes this cross-layer attack progression and the corresponding SOC observables.

Figure 3. Case study: rogue UE registration followed by GTP-U injection. (A) Attack path across 5G layers with the two key telemetry timestamps ($t_{\mathrm{first}\text{\_}\mathrm{observable}}=17:43:04$ UTC, $t_{\mathrm{alert}}=17:43:09$ UTC, $L_d=5$ s). (B) Contrast between a generic SIEM reading of the same telemetry and the protocol-aware 5G-SOC interpretation that reconstructs the injection attempt.

Denial-of-service-like conditions manifested as sudden spikes in signaling rates, elevated deregistration events, abnormal session releases, missing heartbeat messages, and restart storms. The SOC dashboards enabled real-time visualization of these deviations, supporting identification of abnormal load patterns before complete service degradation occurred.

4.4. Responsiveness, Benign Anomalies, and Coverage Summary

The final part of the validation consolidates detection latency, benign anomaly behavior, visualization support, and coverage into a single operational assessment. These dimensions are discussed together because they jointly determine whether a detection is useful in a SOC: fast alerts are insufficient if they are not interpretable, and broad coverage is less valuable if benign instability cannot be distinguished from malicious activity.

4.4.1. Detection Responsiveness

Operational responsiveness was assessed by examining alert generation relative to the first observable anomalous telemetry within the SOC. Policy-driven detections, such as unauthorized identifier appearance, triggered immediately upon log ingestion. Rate- and window-based detections required short observation intervals to confirm sustained abnormal behavior, resulting in modest but operationally acceptable delay.

The integration of logs and Prometheus-based metrics proved particularly valuable in time-sensitive scenarios. For example, PFCP-related anomalies were more clearly interpreted when correlated with simultaneous session count irregularities and component-level health indicators. In the GTP-U injection scenario, the first attack-attributable telemetry event—rogue UE registration at $t_{first\text{\_}observable}=17:43:04$ UTC—was followed by the first UPF [DROP] Source IP-4 Spoofing alert at $t_{alert}=17:43:09$ UTC, yielding $L_d=5$ s.

4.4.2. Benign Anomalies and False Positive Behavior

During benign operational periods, the SOC generated minimal alert noise, indicating stable baseline characterization of normal signaling behavior. However, controlled misconfiguration scenarios—including temporary network function restarts, delayed heartbeats, intentional time synchronization drift, and telemetry degradation—produced telemetry patterns resembling denial-of-service or protocol manipulation conditions.

To substantiate this claim beyond the initial 88-min capture, an extended 29.3-h benign session was subsequently conducted using an automated churn orchestrator that continuously exercised realistic non-malicious network dynamics: 85 individual UE detach/reattach cycles, 171 PDU session release/re-establish cycles, and 9 simultaneous multi-UE reconnection bursts. Throughout the 29.3-h window, all AMF/SMF/PCF/UPF success-rate indicators remained at 100%, with no authentication failures or rejects. Re-running the published detection rules produced at most three alerts and no alerts when the subscriber index was pre-seeded from the HSS/UDR. The only firing rule responded to the first registration of the always-on UEs after monitoring started, not to anomalous behavior.

Rather than eliminating such detections entirely, the framework relied on contextual dashboards to support rapid analyst validation. Visualization of component restarts, resource utilization, heartbeat behavior, and maintenance events enabled differentiation between malicious behavior and operational instability. This highlights a central design principle of the framework: detection accuracy must be complemented by contextual interpretability to minimize analyst burden.

Figure 4 consolidates these operational results in two panels. Panel (A) groups per-scenario detection latency $L_d$ into the discrete buckets of Table 5 (Immediate, Seconds, Sub-5-min, Retrospective). Panel (B) presents false positive rates across benign and degraded conditions using an illustrative, non-linear bar length, chosen so that the low-rate benign baseline and the high-rate restart-cascade condition remain simultaneously legible. Notably, each degraded condition exhibits a distinct false positive fingerprint, which supports the design choice of using contextual dashboards for analyst disambiguation rather than suppressing detections outright.

Figure 4. Operational results. (A) Exercised scenarios of Table 5 grouped into detection-latency buckets (Immediate, Seconds, Sub-5-min, Retrospective). (B) False positive rate (events/hour) under benign and degraded conditions (Table 6). Each degraded condition produces a distinct FP signature, motivating contextual disambiguation over blanket suppression.

Figure 4. Operational results. (A) Exercised scenarios of Table 5 grouped into detection-latency buckets (Immediate, Seconds, Sub-5-min, Retrospective). (B) False positive rate (events/hour) under benign and degraded conditions (Table 6). Each degraded condition produces a distinct FP signature, motivating contextual disambiguation over blanket suppression.

Table 6. False positive behavior under benign and degraded conditions.

Condition	Duration	# Events	FP/h	Most Triggered Categories
Benign baseline traffic (extended)	29.3 h	0–3 a	0.00–0.10	outsider-ue-session rule only (monitoring-start artifact); PFCP heartbeat trace clean and NRF heartbeats maintained
NF restart and SEPP cascade	5 min	∼111	∼1330 burst	Heartbeat loss, N32c/SEPP anomaly, PFCP N4 duplicate, AMF SBI cascade
Time sync drift	2.0 h	≥3	≥1.5	Cross-NF timestamp correlation errors, NTP sync failures, sequence anomalies
Telemetry degradation	12.5 min	≥8	≥38	Agent connectivity loss, missing heartbeats, incomplete session records

^a Range reflects two subscriber-index initialization assumptions (empirically built vs. pre-seeded from the HSS/UDR at monitoring start) for the sole rule that fired; see Section 5. All firings are attributable to the always-on UEs’ first registration after monitoring start, not to anomalous behavior.

Table 6. False positive behavior under benign and degraded conditions.

Condition	Duration	# Events	FP/h	Most Triggered Categories
Benign baseline traffic (extended)	29.3 h	0–3 a	0.00–0.10	outsider-ue-session rule only (monitoring-start artifact); PFCP heartbeat trace clean and NRF heartbeats maintained
NF restart and SEPP cascade	5 min	∼111	∼1330 burst	Heartbeat loss, N32c/SEPP anomaly, PFCP N4 duplicate, AMF SBI cascade
Time sync drift	2.0 h	≥3	≥1.5	Cross-NF timestamp correlation errors, NTP sync failures, sequence anomalies
Telemetry degradation	12.5 min	≥8	≥38	Agent connectivity loss, missing heartbeats, incomplete session records

^a Range reflects two subscriber-index initialization assumptions (empirically built vs. pre-seeded from the HSS/UDR at monitoring start) for the sole rule that fired; see Section 5. All firings are attributable to the always-on UEs’ first registration after monitoring start, not to anomalous behavior.

4.4.3. Operational Visualization and Analyst Workflow

Visualization transforms 5G telemetry and detection outputs into actionable situational awareness within the SOC. In 5G SA environments, where control-plane signaling, user-plane activity, and administrative events occur concurrently across distributed components, effective visualization supports both real-time monitoring and structured investigation.

Dashboards summarize control-plane activity, authentication outcomes, session trends, and alert distributions. Deviations from established baselines—such as spikes in AMF signaling or sudden drops in registered subscribers—serve as indicators of abnormal behavior. Component-centric and protocol-aware dashboards provide detailed insight into individual network functions such as AMF, SMF, UPF, and SEPP. Metrics and log-derived indicators are aligned with each function’s operational role, while time-series representations highlight anomalies such as repeated connection failures, unexpected message sequences, or abnormal heartbeat patterns.

Identifier-centric analysis supports investigations by correlating subscriber activity across sessions and components. By linking authentication events, session lifecycle transitions, and mobility logs, analysts can reconstruct behavioral patterns and detect deviations indicative of rogue devices, credential misuse, or targeted attacks. Trend-based visualization complements event-level monitoring by highlighting recurring patterns, misconfigured rules, and excessive alert noise. Figure 5 shows a simplified reconstruction of the operational SOC dashboard used during the exercises, consolidating KPIs (open alerts, detection coverage, a representative-case detection latency, false positive rate), an alert-rate timeline, network-function health, a recent-alerts feed, and single-click investigation pivots over subscriber, TEID, source-IP, and RAN_ID fields.

Figure 5. Operational SOC dashboard (Elastic Stack) used during the 25–26 March 2026 exercise. This is a schematic reconstruction of the operational dashboard, not a live screenshot. The KPI values shown are illustrative rather than a statistically aggregated mean over repeated runs. They are drawn directly from the scenario instances reported in Table 5: detection coverage matches the coverage matrix presented later in this section, the sample latency is the GTP-U injection case C-2’s $L_d=5$ s, and the false positive rate is the benign baseline range of Table 6. Unlike those three KPIs, the open-alerts count and the alert-events-by-category breakdown are illustrative operational-volume figures rather than values tied to a specific table below. They are also deliberately distinct counts from each other—open, unresolved alerts vs. total category-tagged events raised in the same window—and are not intended to sum to the same total. The view shows headline KPIs (open alerts, detection coverage, sample latency, false positive rate), per-network-function health, and the alert mix by category. A one-line pivot note indicates the identifier fields (subscriber ID, TEID, source IP, RAN_ID) used to reconstruct the attack chain of Figure 3.

Table 7 complements this dashboard view with a qualitative mapping of each attack category to its primary SOC observables, alert type, and investigation pivots, providing a compact reference for analyst triage.

Table 7. Qualitative mapping of attack categories to primary SOC observables, alert type, and investigation pivots.

Attack Category	Primary SOC Observables	Alert Type	Investigation Pivots
Rogue gNB registration	InitialUEMessage from unknown IP; RAN_ID absent from inventory; short session lifetime	Policy	Verify gNB IP inventory; audit sessions via flagged RAN_ID; check prior NGAP attempts
Rogue UE/GTP-U injection	Unknown SUCI/SUPI registration; UPF [DROP] Source IP Spoofing; TEID match	Policy + rate	Correlate TEID with UE session; confirm source IP vs. allocated UE address; check registration timeline
Database credential tampering	Authentication abandoned from UDR/PCF; rapid admin operations; downstream HTTP 404s	Policy	Audit database operations; compare credentials; check subscriber record integrity
SSH brute force	Repeated failed root login attempts across NFs from single source	Rate	Source IP inventory lookup; cross-NF auth log correlation; check successful login events
AMF heartbeat/NRF cascade	Missing heartbeat; SCP timeout storm; stale NF registration state	Reactive	Verify SCP availability, NRF registration state, and cascade origin
SEPP N32c failure	Connection timer expiration on n32c-handshake; repeated retry loop	Reactive	Check peer SEPP DNS/routing, TLS capability exchange, and network path
Monitoring disruption	Monitoring service crash-loop; backend endpoint unreachable	Reactive	Verify backend connectivity, process kill events, and confirm crash-loop onset timing before attributing it to a specific incident
Telemetry degradation	Agent stop events across NFs; coordinated collector restart	Reactive	Audit stop trigger, telemetry gap duration, and affected NFs

Operational use during the exercise suggested that integrated visualization supports situational awareness and investigation efficiency, although this conclusion is based on a single exercise rather than a controlled analyst study (see Section 5). By embedding cross-layer correlation and protocol context directly into analyst-facing views, the SOC framework is intended to support informed decision-making rather than isolated alert handling.

4.4.4. Coverage Summary

The coverage matrix summarizes how the implemented detections performed against the observed threat categories. The matrix distinguishes full coverage, partial coverage, and gaps. Full coverage indicates that the alert fired with cross-component evidence in the current log collection. Partial coverage indicates that the alert fired but required retrospective correlation or analyst disambiguation. A gap indicates delayed recognition, missing evidence, or an unexercised threat category.

Table 8 reports whether each rule fired and how directly but conflates two distinct questions. The first is how the alert was substantiated: real-time cross-component evidence vs. retrospective correlation. The second is how rigorously that substantiation was obtained: a single field observation vs. a controlled, repeated trial. Table 9 makes the second dimension explicit using a four-class evidence taxonomy: E (experimentally tested, with a priori orchestrator ground truth and N repeated trials), O (observed in field/exercise telemetry, single instance), C (fired, but attribution required retrospective correlation), and U (untested). Applied honestly, most rows exercised in this study are class O or C, consistent with the single-instance exercise design of Section 4.1. Two rows, however, were additionally exercised as a live, a priori provisioned, $N=30$ repeated-trial sensitivity check against the authors’ operational testbed (18 August 2026), independent of the exercise telemetry used for every other row. In each trial, a fresh test subscriber attempted registration with the live AMF through a rogue gNB whose network identity and source address differed from those of the benign gNB. Both Unexpected gNB Connection and Outsider UE Session fired on 30/30 planned trials (32/32 including two incidental extra confirmatory runs), with zero NG-Setup failures and a Wilson 95% confidence interval of [88.6%, 100%], qualifying them for class E—the only class-E rows in the table. This result should be read as a repeatability check on one attacker instantiation rather than a population sample. The same rogue-gNB host and identity were reused across all 30 trials. Each trial targeted a distinct, freshly provisioned test-subscriber identity, and the full sequence lasted approximately 84 min. It should likewise be read as a measure of true positive rate rather than false positive rate; the complementary false positive control is the benign baseline re-run described in Section 5. Extending class-E evidence to the remaining rows requires multi-host conditions (per-network-function SSH exposure, per-network-function telemetry agents) that the current single-IP containerized testbed deployment cannot reproduce and remains future work.

Table 8. Detection coverage and correlation assessment.

Threat	Detection Rule	Type	Fired	${\mathit{L}}_{\mathit{d}}$	Coverage
Rogue gNB registration	Unexpected gNB connection attempt	Policy	✓	Immediate	Full: unknown source IP and RAN_ID correlated
Rogue UE registration	New outsider UE session detected	Policy	✓	Immediate	Full: unknown SUCI/SUPI and subscriber lookup failure
GTP-U injection	GTP and PFCP connection issues	Rate	✓	5 s	Full: TEID and source-spoofing events correlated
SSH brute force	Multiple authentication failures	Rate	✓	∼5 min	Full: cross-NF authentication failures aggregated
DB credential tampering	Possible database dump/admin anomaly	Policy	✓	Retro.	Partial: requires downstream UDR/PCF correlation
SSH from IPX to SEPP	SEPP connection anomalies	Policy	✓	Immediate	Partial: intent requires analyst verification
AMF heartbeat loss	Missing heartbeat variant	Reactive	✓	∼30 s	Full: heartbeat loss and NRF state correlated
N32c peer failure	SEPP connection anomalies	Reactive	✓	Immediate	Full: repeated N32c timer expiration observed
Subscriber data loss	Failed SBI messages/NRF discovery	Reactive	✓	Dependent	Partial: downstream artifact of credential issue
Monitoring disruption	Service crash-loop	Reactive	✓	8–9 h	Gap: recognized only in extended retrospective analysis; onset traced to ∼5 days before the SSH brute-force window, ruling out attacker causation and pointing to a pre-existing reliability issue
Telemetry disruption	Agent connectivity loss	Reactive	✓	Immediate	Full: agent stop events observed across NFs
Rogue SEPP registration	SEPP connection anomalies	Reactive	–	n/a	Gap: scenario not exercised in current collection

Note: ✓ indicates the rule fired for the corresponding scenario; – indicates it was not exercised (see the Fired column).

Table 9. Evidence-class fragment for the ablation-exercised rows of Table 8. E = experimentally tested (a priori ground truth, N repeated trials); O = observed in field/exercise telemetry; C = fired, but attribution required retrospective correlation; U = untested.

Rule	Class	Mode A/B	Criterion
Unexpected gNB Connection	E (30/30, 95% CI [88.6%, 100%])	identical	Real-time, single-source; live $N=30$ sensitivity check, 18 August 2026
Outsider UE Session	E (30/30, 95% CI [88.6%, 100%])	identical	Real-time, single-source; live $N=30$ sensitivity check, 18 August 2026
GTP & PFCP Connection Issues	O→C (with correlation)	identical, richer	Fired but attribution needed the TEID join
Multiple Authentication Failures	C	differs (A: no fire)	Fires only with cross-NF aggregation; a generic, protocol-blind global-count baseline also detects it (Section 5), so this is required only relative to a per-NF-isolated baseline
Database Admin Anomaly	C	identical	Downstream corroboration is circumstantial
SEPP N32c Failure	O	identical	Real-time, single-source
SEPP Connection Anomalies (SSH/IPX)	C	identical, richer	Identity mixture needs fingerprint correlation
Missing Heartbeat	O	identical	Real-time, single-source
Telemetry Agent Connectivity Loss	C	differs (A: cannot fire)	Structurally cannot fire without cross-host aggregation
Rogue SEPP Registration	U	–	Scenario not exercised in this dataset

Bold marks rows of particular note: bold E denotes the highest evidence tier (a priori ground truth with N repeated trials); bold Mode A/B entries denote rows where the single-layer and cross-layer detection outcomes differ.

Table 10 summarizes, for the same attack-scenario instances, how each was generated and by whom, making explicit which scenarios were authored on the local testbed versus observed as third-party activity during the exercise. The evidence-class labels of Table 9 (E/O/C/U) describe how rigorously a detection rule’s firing was substantiated; the Source column below instead describes the scenario’s provenance, and intentionally uses different terms (Exercise/Local) to avoid overloading “E” between the two tables.

Table 10. Attack-scenario generation provenance and reproducibility, corresponding to the rows of Table 5. Source: Exercise = observed during the external cyber-defense exercise (third-party red-team or operational activity, telemetry captured but not authored by the authors); Local = author-generated on the local testbed. Most exercise-sourced ground truth is a post hoc reconstruction from correlated logs rather than a priori orchestrator ground truth; see Table 9 for the corresponding per-rule evidence class.

Scenario	Source	Generation Method	Ground Truth/Attribution Basis	N/Duration
Rogue gNB + UE reg. (C-1)	Exercise	Third-party red-team activity during the exercise	Post hoc reconstructed: real-time AMF/journal correlation	1
GTP-U injection (C-2)	Exercise	Third-party red-team activity during the exercise	Post hoc reconstructed: TEID and timestamp correlation (UPF/AMF)	1
SSH brute force (C-1 precursor)	Exercise	Third-party red-team activity during the exercise	Post hoc reconstructed: auth logs (*/auth.log, wildcard: any NF) and source-IP attribution	1
MongoDB admin session (H-1)	Exercise	Third-party red-team activity during the exercise	Post hoc reconstructed: MongoDB oplog and UDR/PCF auth correlation	1
Rogue UE registrations (H-3)	Exercise	Third-party red-team activity during the exercise	Post hoc reconstructed: real-time AMF/journal correlation	1
SSH to SEPP from IPX (H-2)	Exercise	Third-party red-team activity during the exercise	Post hoc reconstructed: sepp/auth.log and sepp/journal	1
AMF heartbeat loss (M-2)	Exercise	Observed during the exercise	Observed exercise event; attacker causation not established	1
SEPP N32c failure (M-3)	Exercise	Observed during the exercise	Observed exercise event; attacker causation not established	1
Rogue gNB + UE reg., sensitivity check	Local	Author-executed: a rogue gNB with a fixed, distinct identity performs NG Setup and NAS registration against the live AMF; a fresh, a priori provisioned test-subscriber identity is used in each trial	A priori orchestrator ground truth: known rogue-gNB/subscriber identities and trial timestamps	30
Benign baseline (extended)	Local	Author-executed: automated churn orchestrator (UE detach/reattach cycles, PDU session release/re-establish cycles, multi-UE reconnection bursts)	A priori orchestrator ground truth: no induced attack traffic	1 run/29.3 h

Figure 6 visualizes the coverage assessment of Table 8 as a per-threat stoplight scorecard, making the two current gaps (rogue SEPP registration and delayed monitoring disruption recognition) explicit as priorities for the next exercise window. Figure 7 then provides an integrated view, tracing each threat scenario from Table 2 through its detection category, reported latency bucket, and terminal coverage class from Table 8.

Figure 6. Detection coverage scorecard. Per-threat coverage class (full/partial/gap) from Table 8, with detection type annotated per row. A highlighted callout identifies the two current coverage gaps (rogue SEPP registration; delayed monitoring disruption recognition) as priorities for the next exercise window.

Figure 7. Threat-to-coverage synthesis. Each threat category (Table 2) is traced to its resulting SOC coverage outcome (Table 8): full (real-time, cross-component evidence), partial (retrospective correlation or analyst disambiguation), or gap (delayed recognition or unexercised). Ribbon color encodes the terminal coverage class; per-category threat counts are annotated on each node. Counts in this figure refer to the 11 threat scenarios of Table 2 and are therefore not directly comparable to the 12 detection-coverage rows summarized in Figure 6.

5. Discussion

The experimental results highlight several important insights regarding security monitoring and attack detection in 5G standalone environments. The most significant observation is that effective detection cannot be treated as an isolated analytical function. Instead, it must be integrated into a broader operational framework that provides context, correlation, and interpretability.

One key finding is the importance of protocol awareness in detection logic. Many attack scenarios, particularly those involving control-plane abuse, rogue network elements, or user-plane manipulation, do not manifest as simple anomalies in traffic volume or error rates. Rather, they appear as deviations in signaling sequences, identifier usage, tunnel semantics, or timing behavior. Without explicit understanding of 5G protocol semantics, such deviations are difficult to distinguish from benign operational irregularities.

Another important observation concerns the dynamic nature of 5G telemetry. Log formats, protocol fields, and operational behaviors evolve rapidly as network functions are updated or reconfigured. Static parsing and rigid detection logic therefore become brittle over time. The combination of structured ingest pipelines and runtime field extraction was found to be important for maintaining adaptability while preserving analytical capability in this deployment.

The evaluation also underscores the importance of contextual visualization in managing false positives. Benign misconfigurations and transient instability occasionally produced telemetry patterns resembling attack behavior. Rather than suppressing such detections entirely, the SOC approach enabled analysts to contextualize alerts using dashboards correlating security events with component health, timing behavior, and maintenance-related activity. This capability is intended to reduce alert fatigue while preserving early warning signals, based on qualitative observation during the exercise rather than a measured reduction in analyst workload.

Finally, the exercise suggests that SOC-integrated detection can support operational decision-making even when detection accuracy is not perfect. By presenting alerts within a coherent operational picture, the SOC enables informed trade-offs between security response, service availability, and investigative effort.

Several limitations must also be acknowledged. The evaluation combined a controlled laboratory testbed with observations from a non-commercial cyber-defense exercise; neither environment represents a large-scale commercial deployment, limiting traffic diversity and subscriber volume. Certain low-rate or stealthy protocol manipulation behaviors remain difficult to distinguish from benign anomalies without adaptive thresholding or statistical modeling. In addition, detection effectiveness depends on telemetry quality and logging granularity; degraded telemetry pipelines or insufficient logging configuration can reduce observability.

Adversarial robustness and evasion. Several of the presented detections rely on indicators such as unknown source IPs or previously unseen RAN identifiers. An adversary aware of the monitoring configuration could attempt to evade these by spoofing known-good identifiers, throttling activity below rate thresholds, or interleaving malicious actions with benign traffic. The framework mitigates—but does not eliminate—such evasion through cross-layer correlation, since evading a single indicator does not necessarily suppress correlated evidence on other layers (for example, a spoofed source IP still leaves a TEID/subscriber mismatch on the user plane). A systematic evaluation of detector evasion and of correlation robustness under adaptive adversaries is an important direction for future work.

Generalizability beyond Open5GS. The telemetry parsing and several detection rules are tailored to Open5GS log formats. The conceptual framework—observability-bounded threat modeling, decision-function-based detection, and cross-layer correlation—is implementation-agnostic, but porting the concrete rules to commercial cores (e.g., Ericsson, Nokia, or Samsung) would require re-mapping vendor-specific log schemas and metrics. The runtime-field approach is expected to ease, but not remove, this adaptation effort; validating transferability across cores remains open. Concretely, porting the current rule set to another vendor core would require the following steps.

(i)

Confirming that the target platform’s logs expose semantically equivalent fields to those relied on here (authentication outcomes, GTP-U tunnel endpoints, NF heartbeat and connectivity events).

(ii)

Mapping these vendor-specific log schemas into a common field structure equivalent to the present parsing layer.

(iii)

Re-validating that the identifier keys used for cross-layer correlation (subscriber identity, TEID, NF identifier, source address) resolve consistently across the new platform’s telemetry.

(iv)

Recalibrating the rate- and time-window-based thresholds used in this study (Section 5.2) against the new platform’s own benign traffic baseline.

(v)

Revalidating the ported rules against a controlled attack scenario on the new platform before operational deployment.

These steps preserve the high-level threat model and correlation principle, but the concrete field mappings, join logic, thresholds, and rule implementations may still require vendor-specific adaptation. Cross-core transferability therefore remains to be validated experimentally.

Toward quantitative and baseline-anchored evaluation. Most exercise-derived attack-scenario results are based on single observed instances of a live, externally sourced attack exercise: most underlying scenarios could not be replayed, re-instrumented, or independently repeated within the manuscript preparation window, so controlled repetition of those scenarios was not feasible at this stage. The present evaluation is therefore primarily behavioral and, for most exercise-derived scenarios, based on single observed instances rather than repeated controlled trials. To strengthen the empirical claims, planned work includes repeating each attack scenario instance under controlled variation of the temporal parameters T to report detection-rate and latency distributions and comparing the proposed 5G-aware SOC against a controlled generic SIEM baseline over identical scenario instances (the dimensions marked as in progress in Table 1). A first step toward this goal has already been taken: false positives were characterized over a 29.3-h benign baseline with realistic churn (Table 6), extending the initial 88-min capture by more than an order of magnitude. One planned element of this run—mid-session onboarding of previously unseen subscribers—did not execute as designed: the orchestrator produced a malformed identifier, which the UE client rejected locally before any network contact occurred. This incidentally shows that malformed identifiers generate no telemetry noise, but it also means the test itself produced no data. Validating detection behavior for legitimate first-time subscriber registration therefore remains for future work. Releasing the detection rules and ingest pipelines as open artifacts is intended to support independent scrutiny of the detection logic; the underlying telemetry originates from a third-party exercise and cannot be redistributed, which is itself a motivation for the controlled, self-generated replication described above.

The comparative observations below further clarify why the contribution should be interpreted as a SOC-integrated framework rather than as a set of standalone detection rules. Classical IDS evaluation frequently focuses on classification-oriented metrics such as precision, recall, and detection accuracy over static datasets. In operational SOC environments, however, the interpretation of telemetry is equally important: identical low-level events may represent either benign operational noise or a meaningful attack chain depending on protocol semantics, contextual enrichment, and cross-layer correlation.

Accordingly, the comparative perspective adopted in this work does not compare the proposed framework against a separate standalone IDS implementation. Instead, it evaluates how the same observable telemetry would be interpreted under (i) a generic SIEM-oriented monitoring approach vs. (ii) the proposed 5G-aware SOC-integrated detection model. The comparison emphasizes operational interpretability, investigation quality, and the ability to reconstruct attack semantics from distributed telemetry sources. This comparison is interpretive rather than a controlled empirical benchmark; Section 5.2 reports where an empirical generic SIEM baseline was additionally implemented and run.

5.1. Protocol-Aware Interpretation vs. Generic Event Monitoring

Several attack scenarios demonstrated that isolated telemetry events are often insufficient for reliable interpretation in 5G environments. Generic SIEM pipelines typically process such events as independent log anomalies or service failures, whereas protocol-aware contextualization allows reconstruction of the underlying attack sequence.

The GTP-U injection scenario provides a representative example. At the user-plane level, the UPF generated repeated [DROP] Source IP-4 Spoofing entries associated with TEID 0x9031. In a conventional SIEM environment, these events would likely appear as generic UDP anomalies or isolated packet-filtering events. Within the proposed framework, however, the same telemetry was correlated with a preceding rogue UE registration event involving an unknown subscriber identifier and the same tunnel context. This transformed the interpretation from a generic network anomaly into a protocol-consistent user-plane injection attempt targeting an active tunnel.

A similar distinction was observed during rogue gNodeB activity. Generic monitoring identified an unknown IP initiating NGAP communication with the AMF. The 5G-aware SOC interpretation additionally incorporated the previously unseen RAN identifier, abnormal UE session lifetime, and outsider session behavior, collectively indicating probable rogue radio infrastructure rather than ordinary connection instability. A similar pattern appeared during control-plane failures, where AMF heartbeat loss alone resembled ordinary service degradation. Correlation with SCP retry storms, NRF deregistration state, and SBI anomalies instead revealed cascading control-plane instability.

Figure 8 illustrates this interpretive difference qualitatively, contrasting for each scenario the raw, context-free reading a generic SIEM would report against the protocol-aware, cross-layer interpretation the proposed SOC reconstructs from the same telemetry. Across the scenarios considered, the SOC-lens reading consistently adds correlated context—linked identifiers, cross-NF causality, or a ruled-out alternative hypothesis—that the generic SIEM reading lacks, with the SEPP N32c case being the closest to a tie. We stress that this is an interpretive-depth comparison rather than a controlled quantitative benchmark. We do not assign it a numeric score, since no explicit, validated rubric for counting “correlated context dimensions” was defined in advance; a controlled generic SIEM baseline is identified as future work below.

Figure 8. Generic SIEM vs. 5G-aware SOC interpretation for six representative scenarios (Table 11), short-form. Each row contrasts the raw, context-free reading a generic SIEM would report against the protocol-aware, cross-layer interpretation the proposed SOC reconstructs from the same telemetry.

Figure 8. Generic SIEM vs. 5G-aware SOC interpretation for six representative scenarios (Table 11), short-form. Each row contrasts the raw, context-free reading a generic SIEM would report against the protocol-aware, cross-layer interpretation the proposed SOC reconstructs from the same telemetry.

Table 11. Generic SIEM vs. 5G-aware SOC interpretation.

Scenario	Generic SIEM Interpretation	5G-Aware SOC Interpretation
GTP-U spoofing burst	Repeated UDP DROP events with abnormal source addresses; appears as isolated network anomaly	Correlated with prior rogue UE registration and TEID allocation, reconstructing a user-plane injection attempt targeting an active tunnel
Rogue gNodeB registration	Unknown IP initiating NGAP connection	Unrecognized RAN_ID combined with abnormal session lifetime and outsider UE activity indicates rogue radio element behavior
AMF heartbeat loss	Service availability warning	Correlated with SCP retry storm and NRF deregistration state, indicating cascading control-plane instability
Telemetry degradation	Agent disconnect or logging outage	An initial working hypothesis of attacker-induced disruption was tested and rejected: extending the retrospective window traced the crash-loop onset to ∼5 days before the SSH brute-force activity, indicating a pre-existing reliability issue rather than a causal link
Subscriber lookup failures	Repeated HTTP 404 or database-related application errors	Correlated with prior MongoDB administrative activity and UDR authentication disruption, indicating possible credential tampering or subscriber data inconsistency
SEPP N32c retry storm	Persistent external connection failure	Interpreted as roaming-path instability affecting inter-network trust establishment and signaling continuity

Table 11. Generic SIEM vs. 5G-aware SOC interpretation.

Scenario	Generic SIEM Interpretation	5G-Aware SOC Interpretation
GTP-U spoofing burst	Repeated UDP DROP events with abnormal source addresses; appears as isolated network anomaly	Correlated with prior rogue UE registration and TEID allocation, reconstructing a user-plane injection attempt targeting an active tunnel
Rogue gNodeB registration	Unknown IP initiating NGAP connection	Unrecognized RAN_ID combined with abnormal session lifetime and outsider UE activity indicates rogue radio element behavior
AMF heartbeat loss	Service availability warning	Correlated with SCP retry storm and NRF deregistration state, indicating cascading control-plane instability
Telemetry degradation	Agent disconnect or logging outage	An initial working hypothesis of attacker-induced disruption was tested and rejected: extending the retrospective window traced the crash-loop onset to ∼5 days before the SSH brute-force activity, indicating a pre-existing reliability issue rather than a causal link
Subscriber lookup failures	Repeated HTTP 404 or database-related application errors	Correlated with prior MongoDB administrative activity and UDR authentication disruption, indicating possible credential tampering or subscriber data inconsistency
SEPP N32c retry storm	Persistent external connection failure	Interpreted as roaming-path instability affecting inter-network trust establishment and signaling continuity

The experimental results further suggest that cross-layer telemetry correlation provided additional investigation pivots during the observed exercise, based on qualitative observation rather than a controlled analyst-time study (Section 5). Instead of interacting with isolated alert fragments, analysts were able to pivot between signaling logs, user-plane events, infrastructure metrics, and subscriber-related context within a unified operational timeline.

This capability proved particularly valuable during multi-stage attack sequences. In the rogue UE and GTP-U injection scenario, the SOC reconstructed the sequence from initial registration through tunnel establishment to spoofed packet injection. Individually, none of these events alone provided sufficient confidence for high-severity escalation. Their temporal and protocol-level correlation, however, established a coherent attack narrative.

Similarly, telemetry degradation events initially resembled ordinary logging instability, and their rough temporal proximity to concurrent SSH brute-force activity suggested a working hypothesis of attacker-induced monitoring disruption intended to reduce observability. Extending the retrospective timeline to trace the crash-loop’s actual onset, however, showed the restarts beginning approximately five days before the brute-force window, which rules out a causal link and instead points to a pre-existing operational reliability issue independent of the attack. We report this correction rather than the original hypothesis because it illustrates a broader point: cross-layer telemetry supports not only attack reconstruction but also the falsification of plausible-looking but incorrect correlation hypotheses, which is itself a useful SOC capability. These findings reinforce the central premise of this work: effective detection in operational 5G environments depends on reconstructing protocol-aware context across distributed telemetry sources, including the discipline to test rather than assume temporal coincidence.

5.2. Quantitative Ablation: Single-Layer vs. Cross-Layer Detection

To move beyond the qualitative interpretive-depth comparison above, the published detection rules were reimplemented independently in a lightweight, Elastic-independent harness. This harness was executed twice against the same 25–26 March 2026 exercise telemetry: once restricted to single-source (“Mode A”) evidence per rule, and once with cross-layer aggregation and identifier correlation enabled as designed (“Mode B”). This constitutes a genuine ablation of the correlation component, holding the detection rule logic and underlying telemetry fixed, rather than a repeated-trial statistical study.

Under the per-network-function-isolated Mode A, two of the nine exercisable rules did not fire. The multiple authentication failures rule (SSH brute force, threshold ≥5 distinct hosts/≥20 attempts within 30 min) did not trigger under Mode A. The busiest single network function observed only 18 failed attempts from the source, one below the aggregate threshold, because the attacker distributed attempts thinly across all 13 network functions. Under Mode B, aggregating the same events by source IP across hosts yielded 216 attempts across 12 network functions, triggering the alert. Similarly, the telemetry agent connectivity loss rule (threshold ≥3 distinct hosts within 20 min) is structurally incapable of firing under single-source telemetry, since any one network function’s own log can only ever report its own agent stopping. Cross-layer aggregation, in contrast, observed 7 network functions’ agents stopping within 1200 s of each other, triggering the alert. A caveat applies to the first case: a protocol-blind, generic-SIEM-style baseline that simply counts failed logins globally by source IP—without any 5G-specific parsing—also catches the brute force (215 failed logins aggregated). Basic cross-host aggregation is therefore not itself a 5G-specific capability; the differentiator the proposed framework adds over realistic generic tooling is 5G-semantic attribution (tying the alert to a specific actor who later reappears as a rogue gNodeB, RAN_ID, or forged subscriber identity), not raw detection. The telemetry-loss finding is unaffected by this caveat and remains the cleaner example of correlation as a structural precondition for detection.

A further three rules fired identically under both modes but gained corroborating evidence from correlation. The GTP-U injection rule fired on UPF telemetry alone; cross-layer correlation upgraded the classification from an isolated user-plane anomaly to a confirmed injection attempt via a TEID and timing join against the preceding rogue registration event. The database admin anomaly rule fired on the MongoDB admin-session threshold alone; correlation against downstream authentication failures in dependent network functions provided corroborating, though still circumstantial, support for the credential-tampering interpretation. The SEPP/IPX SSH rule fired on traffic volume alone; correlation against known-identity key fingerprints revealed a three-way mixture of known monitoring infrastructure, a second distinct automation identity, and unattributed password-based attempts, a more nuanced picture than a single volume threshold conveys. The remaining four rules (unexpected gNB connection, outsider UE session, SEPP N32c failure, missing heartbeat) are single-source by design and show no Mode A/B difference on this telemetry; two of them are, however, additionally supported by the live $N=30$ repeated-trial evidence discussed below. Table 12 summarizes the outcome per rule.

Table 12. Single-layer (Mode A) vs. cross-layer (Mode B) detection outcome, reimplemented independently from the published detection rules (Table 4) and run directly against raw telemetry.

Rule	Mode A	Mode B	Effect of Correlation
Multiple Authentication Failures	Does not fire (18/20 attempts, busiest single NF)	Fires (216 attempts/12 NFs)	Required under per-NF-isolated monitoring; a generic, protocol-blind global-count baseline also detects this attack, so the differentiator is 5G-semantic attribution, not raw multi-host aggregation
Telemetry Agent Connectivity Loss	Cannot fire (rule requires ≥3 hosts by definition)	Fires (7 NFs/ 1200 s)	Required for detection
GTP & PFCP Connection Issues	Fires	Fires	Upgrades interpretation (isolated anomaly → confirmed injection)
Database Admin Anomaly	Fires	Fires	Adds corroborating downstream evidence
SEPP Connection Anomalies (SSH/IPX)	Fires	Fires	Reveals 3-way identity mixture, not single ambiguity
Unexpected gNB Connection	Fires	Fires	No effect on this telemetry (single-source by design); see Table 9 for the live $N=30$ result
Outsider UE Session	Fires	Fires	No effect on this telemetry (single-source by design); see Table 9 for the live $N=30$ result
SEPP N32c Failure	Fires	Fires	No effect (single-source by design)
Missing Heartbeat	Fires	Fires	No effect (single-source by design)

As a false positive control, the same Mode B rule set was independently re-run against the 29.3-h benign baseline described in Section 4. The rerun reproduced the only false positive already reported in Table 6: the outsider-UE-session rule fired when the always-on UEs registered for the first time after monitoring started. Pre-seeding the subscriber index from the benign run’s own ground-truth log suppressed the alert entirely. This corroborates the existing Table 6 finding, using an independently written detection engine that operates directly on raw telemetry rather than through the deployed Elastic pipeline.

This ablation should be read alongside, not in place of, repeated-trial evaluation. It shows that cross-layer correlation is necessary to detect at least one of the nine exercised attack techniques under per-NF-isolated monitoring. It also strengthens confidence in the interpretations produced for three other rules, although this evidence comes from the same single exercise instance rather than independently repeated executions. For two of the nine rules (unexpected gNB connection, outsider UE session), a genuine $N=30$ repeated-trial evaluation was additionally performed live against the operational testbed on 18 August 2026 (Table 9). The same rogue gNB was reused across all 30 trials against the real AMF. Its network identity and source address differed from those of the always-on benign gNB. The trials were conducted 90 s apart. In each trial, a fresh, a priori provisioned test subscriber attempted registration through the rogue gNB. All 30 planned trials (32/32 including two incidental extra confirmatory runs) completed a full NG setup procedure and a full NAS registration, with zero NG setup failures; both rules fired on every trial (Wilson 95% CI [88.6%, 100%]). This is a repeatability check on one attack instantiation and a measure of sensitivity, not a population sample or a specificity measure. The remaining seven rules still rely on the single-instance retrospective evidence above, since the multi-host conditions their detection logic requires (per-NF SSH exposure, per-NF telemetry agents) are not reproducible in the current single-IP containerized deployment.

5.3. Operational Implications

The comparative observations suggest that SOC-integrated, protocol-aware monitoring provides several operational advantages over generic event-centric monitoring approaches. First, contextual enrichment reduces ambiguity by embedding protocol semantics directly into alert interpretation. Second, cross-layer correlation improves attack reconstruction and enables earlier identification of multi-stage activity. Third, integrated dashboards and telemetry pivots are designed to reduce analyst investigation effort. They present infrastructure state, signaling behavior, and security alerts within a unified operational context. This is a design objective observed qualitatively during the exercise rather than a measured effect, since no controlled analyst-time study was conducted (Section 5).

Rather than replacing traditional IDS logic, the proposed framework complements existing detection techniques by improving operational interpretability and situational awareness. This distinction is particularly important in 5G environments, where attacks frequently manifest as subtle deviations across multiple distributed components rather than isolated high-confidence signatures. Overall, the experimental exercise suggests that embedding protocol-aware detection within a 5G-specific SOC architecture can enhance situational awareness and operational responsiveness; confirming this effect at scale requires the repeated, baseline-anchored evaluation identified above. Rather than optimizing solely for statistical classification accuracy, the proposed approach prioritizes operational viability, interpretability, and cross-layer correlation.

6. Conclusions

This paper presented a SOC-integrated framework for specialized attack detection in 5G standalone environments, emphasizing operational observability, protocol awareness, and cross-layer correlation. Rather than treating detection as an isolated analytical component, the proposed approach embeds 5G-specific telemetry processing and decision logic directly into a security operations center architecture designed to support real-world monitoring workflows.

Through the design and deployment of a controlled experimental 5G SA environment, we demonstrated how heterogeneous control-plane, user-plane, and administrative telemetry can be normalized, correlated, and visualized within a unified SOC platform. The study showed that realistic 5G threat scenarios—including rogue network elements, authentication abuse, control-plane manipulation, and signaling-based denial-of-service conditions—produce distinct operational footprints that can be surfaced when detection logic is aligned with protocol semantics and contextual enrichment.

The evaluation focused on behavioral responsiveness, interpretability, and analyst usability rather than purely statistical classification metrics. Observations from this structured attack exercise suggest that integrating protocol-aware detection into SOC workflows can support situational awareness and timely investigation and can help reduce ambiguity between malicious activity and operational instability. A quantitative single-layer vs. cross-layer ablation (Section 5.2) and a live, $N=30$ repeated-trial sensitivity check provide an initial, rule-scoped quantitative grounding for these observations. Extending comparable repeated-trial evidence to the remaining detection rules, and confirming these effects at larger operational scale, are identified as future work.

Beyond the specific detection cases presented, the primary contribution of this work lies in establishing a methodological bridge between 5G security research and operational SOC practice. The framework provides a reproducible abstraction for modeling detection as a time-bounded decision process over observable telemetry, while preserving adaptability to evolving log formats and deployment configurations.

Future research may extend this work through large-scale quantitative validation, adaptive thresholding, and machine-learning-assisted anomaly modeling. Additionally, integration with automated response mechanisms and cross-domain correlation in edge-enabled or sliced 5G deployments represents a promising direction. As 5G infrastructures become more programmable and architecturally complex, security monitoring must similarly shift from isolated detection techniques toward integrated, operationally grounded defense systems. The SOC-centric approach presented in this paper offers a practical and extensible foundation for securing next-generation mobile networks.