← Book home
Part 6 · Threats, Attacks, and Operator Protection
26

5G Security Monitoring and KPIs

You cannot defend what you cannot see — building the telemetry

"The standard tells you what should happen. Monitoring tells you what is happening. The gap between them is where every incident lives." — WHY SECURITY TELEMETRY MATTERS

A perfectly configured 5G network still needs eyes. Authentication failures, registration anomalies, API abuse, roaming attacks, and misconfiguration drift all show up first in telemetry — if you collect it. This chapter builds the 5G security telemetry stack: which events to log from which NFs, the KPIs that reveal attacks, and how NWDAF can assist anomaly detection.

🎯 Learning objectives
📘 Standards reference box — Chapter 26
ReferenceTitleNote
TS 33.5015G security (event sources)Rel-18, v18.11.0 (2026-04)
TS 23.288NWDAF — network data analyticsRel-18/19 edition
TS 28.5xxManagement & performance (logs/KPIs)Rel-18 edition

Checked June 2026 — verify against the latest 3GPP version.

26.1 The Telemetry Architecture

FIGURE 26.1Security Telemetry Architecture — Sources to SIEM
AMF AUSF/UDM NRF SEPP NEF / gNB collection pipelinenormalize · enrichtag (NF, slice, partner) SIEMcorrelation, alertsSOC use cases (Ch27) NWDAFanalytics / anomaly(§26.6) SOCanalysts + playbooks tag every event with NF, slice, and roaming-partner context → most detections are "anomaly within a context," not absolute thresholds
Purpose: the pipeline. NFs emit events; collection normalizes and contextualizes them (NF, slice, partner); SIEM and NWDAF analyze; the SOC acts. Context tagging is what makes detection precise.
FIGURE 26.2AMF Event Catalog Worth Collecting
AMF event why it matters authentication result (success/fail + cause)funnel, FBS detection (§26.3) security mode (NEA/NIA selected)null-crypto drift alarm registration (type, identity used)SUCI vs cleartext, anomaly NAS integrity failurestampering / attack signal mobility / paging anomaliestracking, GUTI hygiene
Purpose: the AMF is the richest security source. These events feed the authentication funnel, drift alarms, and anomaly detection — collect them all.
FIGURE 26.3The Authentication Funnel and Failure Taxonomy
authentication attempts challenge issued success drop-off = failures: MAC failure → FBS? sync failure → SQN/DB no-response → coverage/DoS timeout → core overload monitor each failure CAUSE separately — a spike in one bucket means something very different than a spike in another (Ch 6)
Purpose: the single most valuable security view. A failure spike's cause (Chapter 6) determines the response — MAC failures suggest a rogue gNB; sync failures suggest a database issue.
FIGURE 26.4AUSF / UDM Analytics
home-side security signals SUCI de-concealment failures (tampering/garbage) RES* mismatch rate (auth integrity) null-scheme registration share (privacy drift) result-confirmation anomalies (roaming fraud) the home network sees the AUTHORITATIVE auth picture — its analytics catch what the visited side can't
Purpose: the home network's privileged view. AUSF/UDM see the authoritative authentication outcome and SUCI handling — including the null-scheme KPI from Chapter 4.
FIGURE 26.5NRF Log Goldmine — Discovery and Token Patterns
the NRF sees the whole SBA's intentions discovery requests (who's looking for whom), token issuance (who's authorized for what), registration changes (rogue NF?) unusual discovery patterns = reconnaissance; unexpected token requests = lateral-movement attempt (Ch 10, 24) because the NRF authorizes everything, its logs are a near-complete map of SBA behavior — and abuse
Purpose: the NRF as a sensor, not just a target. Its discovery and token logs reveal SBA reconnaissance and lateral-movement attempts (Chapter 24).
FIGURE 26.6SBA API Logging Pipeline
inter-NF callcaller, scope, audience log (structured)result, latency, token SIEM correlationabuse/anomaly alert / forensics structured SBA logs (caller/scope/audience/result) make both abuse detection and post-incident forensics possible
Purpose: log the SBA like the web platform it is. Structured per-call logs are both the detection feed and the forensic record for the core.
FIGURE 26.7SEPP / Roaming Log Analysis
per-partner roaming telemetry message-type distribution per partner · filtering drops · unexpected location/registration queries · volume anomalies a partner suddenly sending location queries it never sent before = interconnect attack signal (Ch 13) pull SEPP logs FIRST for any roaming incident
Purpose: the roaming sensor. Per-partner baselines turn the SEPP's filtering into a detection feed — a partner's behavior change is an early attack signal (Chapter 13).
FIGURE 26.8NAS Security Failure Decision Tree
NAS security failure integrity failure (MAC)tampering / injection?→ investigate path, FBS replay (COUNT)captured-resend?→ usually blocked, log capability mismatchbidding-down attempt orSN-name config (Ch 5,8)
Purpose: route NAS failures correctly. Each type points to a different cause and investigation — integrity failures to tampering, capability mismatches to bidding-down or config (Chapters 5, 8).
FIGURE 26.9Suspicious Registration Patterns
burst from one areaFBS or IoT storm repeated failuresattack / misconfig odd identity typescleartext / null scheme off-hours spikesautomation / botnet these patterns are your highest-signal early warnings — build alerts for each
Purpose: the early-warning gallery. These registration patterns precede many incidents; each deserves a standing alert.
FIGURE 26.10The 5G Security KPI Dashboard
CORE SECURITY KPIs null-crypto / null-scheme %target: ~0 (emergency only) auth success rate+ failure-cause breakdown NAS/AS integrity failuresspike = investigate SEPP filtering dropsper partner API rate / quota breachesper AF (Ch 12) mapped-context sharedowngrade tracking (Ch17) + NRF token anomalies · GUTI age · registration-pattern alerts · cert expiry countdown
Purpose: the standing dashboard. These KPIs operationalize the whole book — each maps to a mechanism chapter and a misconfiguration (Chapter 25).
FIGURE 26.11NWDAF-Assisted Anomaly Detection Loop
network dataNFs, events, KPIs NWDAFmodel normal,flag anomalies anomaly alertsto SOC (Ch 27) SOCtriage feedback: confirmed incidents refine the models NWDAF complements (not replaces) rule-based detection — Chapter 31 covers ML risks
Purpose: the 3GPP-native analytics function. NWDAF models normal behavior and flags anomalies — a complement to rules, with its own risks (Chapter 31).
FIGURE 26.12Alert Severity and Routing
INFO / LOWdashboard, trendno page MEDIUMSOC analyst tickete.g. null-scheme drift HIGHon-call, playbooke.g. MAC-failure cluster CRITICALmajor incidente.g. UDM/NRF compromise tune thresholds to avoid alert fatigue — a SOC that ignores alerts is worse than no alerts
Purpose: turn telemetry into action without drowning the SOC. Severity-based routing connects KPIs to the playbooks of Chapter 27 — and avoids alert fatigue.

26.2 The Practical Operator View

26.3 Threats Detected by KPI

KPI / signalDetectsChapter
MAC-failure cluster (geo)rogue gNB6,24
Sync-failure spikeSQN/DB issue (usually not attack)6
Null-scheme/null-crypto %privacy/config drift4,8,25
SEPP filtering drops / partner anomalyinterconnect attack13
API rate/quota breachesscraping/abuse12
NRF token anomaliesrecon/lateral movement10,24
Registration burstFBS or signaling storm23,24

26.4 Terminology

TermMeaning
SIEMSecurity Information and Event Management (correlation/alerting)
NWDAFNetwork Data Analytics Function (3GPP-native analytics)
authentication funnelAttempts → success, with failure-cause breakdown
drift alarmAlert when config/behavior deviates from baseline

Real network example. A SOC analyst noticed the authentication-success KPI dip by 2% in one region — small enough that an aggregate "auth success rate" alarm never fired. Because the operator had split the funnel by failure cause, the analyst saw the dip was entirely MAC failures, clustered in a few adjacent cells, starting at 2 a.m. That signature — MAC failures (not sync), geographically clustered, off-hours — is the fingerprint of a false base station (Chapter 6). A field team found a rogue gNB in a parked van. Had the operator only tracked aggregate success rate, the attack would have hidden inside normal variance. The cause breakdown, not the headline number, is what catches the attack.

★ Chapter Summary

? Review Questions

  1. Why tag every security event with NF/slice/partner context?
  2. Why split the authentication funnel by failure cause, and what does a MAC-failure cluster indicate?
  3. How is the NRF a security sensor, not just a target?
  4. What roaming-attack signal appears in SEPP logs?
  5. Name five KPIs in the security dashboard and what each detects.
  6. How does NWDAF complement rule-based detection?
  7. Why is alert severity routing important?
  8. An aggregate auth-success KPI looks fine but an attack is underway. How could the cause breakdown reveal it?
🧪 Mini lab — build the funnel

In Open5GS, enable verbose AMF/AUSF logging and run several UERANSIM registrations including induced failures (wrong key → MAC failure; stale SQN → sync failure). (1) Build the authentication funnel: attempts → success, with failures bucketed by cause. (2) Inject a cluster of MAC failures and confirm your funnel highlights the cause, not just a dip in success. (3) Add a null-scheme/null-crypto KPI from the security-mode events. (4) Define the severity and routing for each: which is a dashboard trend, which pages on-call? You've now built the detection layer that turns the configured protections of this book into observable security.

← Chapter 25 Chapter 26 Chapter 27 →