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

The 5G Threat Model

Every surface, every actor, on one map you can defend from

"You cannot defend what you have not enumerated. A threat model is the map; everything in Part 6 is how you patrol it." — WHY THIS CHAPTER OPENS PART 6

This chapter assembles a complete 5G threat model — every attack surface from the device to the cloud, the actors who exploit them, and a risk ranking to prioritize defense. It is the consolidation of the threats raised throughout the book, mapped to industry frameworks (MITRE FiGHT, GSMA), and the springboard for the monitoring, SOC, and audit chapters that follow.

🎯 Learning objectives
📘 Standards reference box — Chapter 24
ReferenceTitleNote
TS 33.5015G security architecture (controls)Rel-18, v18.11.0 (2026-04)
TR 33.926Threat & risk analysis for SCASRel-18 edition
MITRE FiGHT5G adversarial TTP knowledge basecurrent
GSMA FS.31/FS.405G security guidelinescurrent

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

24.1 The Master Threat Map

FIGURE 24.1Master Threat Map — Every Surface on One Page
UE gNB transport CORE / SBA AMFUDMNRF NEFSEPP internet partner PLMN cloud / K8s layer (underlies core) OAM / insider (controls core) 1 2 3 4 5 6 7 8 1 UE/device · 2 air/RAN · 3 transport · 4 core/SBA · 5 API/NEF · 6 roaming · 7 cloud · 8 insider/OAM
Purpose: the consolidated attack surface. Eight branches, each expanded below — this is the map the SOC (Chapter 27) and audit (Chapter 28) patrol.
FIGURE 24.2Threat Actor Gallery — Capability × Intent
capability → intent/impact ↑ scriptkiddie criminal(fraud) hacktivist insider(trusted) nationstate prioritize for the actors your network actually faces — critical infrastructure faces nation-states & insiders, not just script kiddies
Purpose: match defenses to adversaries. A consumer eMBB network and a national-grid slice face very different actors; the threat model must reflect who actually targets you.
FIGURE 24.3UE / Device Threat Branch
UE / device malware / rogue apps credential/session-key theft SIM swap / cloning jailbreak / tampering fleet compromise (IoT, Ch23) capability/measurement leak defensesUSIM root, ME hardening,EIR, fleet monitoring
Purpose: device-side threats. The ceiling is bounded by the USIM (Chapter 4), but malware, SIM swap, and fleet compromise remain real — countered by hardware roots and device monitoring.
FIGURE 24.4Air Interface & RAN Threat Branch
RAN false base station (rogue gNB) jamming / DoS on radio passive sniffing (metadata) F1/Xn/backhaul tap (Ch14-15) physical site access downgrade to NSA/LTE (Ch18) defensesmutual auth, AS integrity,IPsec, secure boot, FBS detect
Purpose: the radio and RAN threats. Mutual authentication (Chapter 5) kills the classic false base station on SA; jamming, sniffing, transport taps, and downgrade survive and need their own controls.
FIGURE 24.5Rogue gNB / False Base Station Scenario
UE rogue gNB lure with strong signal on 5G SA: ✓ mutual auth → can't complete MitM (AUTN fails) ⚠ can still attempt downgrade, DoS, or cause MAC-failure clusters detection: clustered MAC failures (Ch6), FBS sensors
Purpose: the canonical RAN attack, post-5G. Mutual authentication stops the man-in-the-middle, but the rogue gNB can still disrupt — and clustered MAC failures (Chapter 6) are its signature.
FIGURE 24.6Core / SBA Threat Branch
core / SBA lateral movement (no OAuth) NRF compromise / token forgery rogue NF registration UDM/key theft NF software vulnerabilities plaintext SBI ("internal safe") defensesmTLS+OAuth,HSM, hardening
Purpose: the SBA threats (Chapters 10–11). The new web-style core inherits web-style attacks; mTLS+OAuth, NRF hardening, and HSM-protected keys are the answers.
FIGURE 24.7Lateral Movement Inside an SBA Core
NF-A UDM (no token → 403) scope only ✓ NRF (no token → 403) OAuth scope + audience contain it a compromised NF can only do what its tokens permit (Ch 10) without OAuth, one foothold = whole core
Purpose: why per-operation authorization matters. With OAuth scope/audience, a compromised NF is boxed in; without it (mTLS only), one foothold owns the core (Chapter 10).
FIGURE 24.8API / Exposure Threat Branch
NEF / APIs location surveillance abuse scraping (no rate limit) injection / over-exposure trusted-AF bypass broken object-level authZ defensesCAPIF, 3-dim authZ,quota, minimization (Ch12)
Purpose: exposure threats (Chapter 12). The northbound is a web API with web-API threats; the controls are CAPIF, three-dimensional authorization, quotas, and data minimization.
FIGURE 24.9Roaming / Interconnect Threat Branch
SEPP / N32 subscriber location tracking fake registration / intercept key/vector theft in transit malicious IPX modification defensesSEPP filtering, PRINS,topology hiding (Ch13)
Purpose: roaming threats (Chapter 13). The SS7/Diameter attack classes survive at the interconnect; the SEPP's filtering, PRINS, and topology hiding are the defenses.
FIGURE 24.10Cloud / NFVI Threat Branch
cloud / K8s container escape → host secrets exposure supply-chain (images/CI) multi-tenant side channel defensesCNF hardening, secretsmgmt, supply chain (Ch29)
Purpose: cloud threats (Chapter 29). The core is now software on Kubernetes, inheriting cloud-native attacks — container escape, secrets exposure, and supply-chain compromise lead the list.
FIGURE 24.11Supply Chain Threat Path
compromised dependency/ base image CI/CD pipelinebuilds it in registrysigned? scanned? production NFruns the backdoor defense: image signing/scanning, SBOM, pipeline security (Ch 29) — catch it before production
Purpose: the modern indirect attack. A backdoored dependency or image rides the pipeline into production; signing, scanning, and SBOM (Chapter 29) intercept it.
FIGURE 24.12Insider Threat Vectors
insider(trusted) privileged OAM abuse key export from UDM/HSM path config tampering (disable security) data/subscriber exfiltration log tampering / cover tracks defensesMFA, least priv,audit, separation
Purpose: the hardest threat — trusted access. Insiders bypass perimeter controls; least privilege, MFA, immutable audit logs, and separation of duties are the defenses.
FIGURE 24.13MITRE FiGHT Mapping of Chapter Threats
map your threats to MITRE FiGHT (5G adversary TTPs) a common language across reconnaissance → initial access → execution → persistence → exfiltration, specialized for 5G benefit: shared vocabulary with SOC tooling, threat intel, and detection engineering (Ch 26-27)
Purpose: speak the industry's language. Mapping threats to MITRE FiGHT connects your model to detection tooling, threat intel, and the SOC (Chapters 26–27).
FIGURE 24.14Risk Matrix — Likelihood × Impact
likelihood → impact ↑ UDM/key theft NRF compromise roaming interconnect abuse signaling storm (IoT) API location abuse insider key export false base station (SA) UE malware low-likelihood / high-impact prioritize the upper-right
Purpose: turn the model into priorities. Plot each threat by likelihood and impact; defend the upper-right first. This drives the audit and monitoring focus of Chapters 26–28.
FIGURE 24.15The Threat Model's Output — a Ranked Risk Register
#riskprimary controlchapter 1UDM/key theftHSM, no export11,29 2NRF compromiseharden, mTLS, token validation10,11 3roaming interconnect abuseSEPP filtering, PRINS13 4insider key exportMFA, least priv, audit11,30 5SBA lateral movementOAuth scope/audience10 signaling storm, API abuse, FBS, cloud escape…overload control, quotas, hardening23,12,29 the threat model isn't a diagram — it's a LIVING RANKED REGISTER that drives audit (Ch28) and monitoring (Ch26)
Purpose: the deliverable. A threat model's value is a ranked, owned, control-mapped register that the audit and SOC chapters operationalize — not a one-time diagram.

24.2 The Practical Operator View

Common gaps

24.3 Threats and Mitigations (Top-Level)

BranchHeadline threatPrimary control · chapter
UE/devicemalware, SIM swap, fleet compromiseUSIM root, EIR, fleet monitoring · 4,23
RAN/airrogue gNB, downgrade, transport tapmutual auth, IPsec, FBS detect · 5,14,15
Transportinterception/injectionNDS/IP IPsec · 14
Core/SBAlateral movement, NRF/UDM compromisemTLS+OAuth, HSM · 10,11
API/NEFsurveillance, scrapingCAPIF, quota, minimization · 12
Roamingtracking, fraud, key theftSEPP filtering, PRINS · 13
Cloudescape, secrets, supply chainCNF hardening · 29
Insiderprivileged abuse, key exportMFA, least priv, audit · 11,30

24.4 Terminology

TermMeaning
threat modelEnumeration of surfaces, actors, threats, and controls
MITRE FiGHT5G adversary tactics/techniques knowledge base
risk matrix / registerLikelihood×impact ranking driving prioritization
attack surfaceThe set of points an attacker can target

Real network example. A national operator's first 5G threat model was a slide deck listing radio attacks — false base stations, jamming — because that's what the RAN team knew. A subsequent independent assessment found the highest-impact risks were entirely absent: insider key export from the UDM, NRF compromise enabling SBA-wide impersonation, and roaming-interconnect abuse. The model had been written from one team's perspective and missed the crown jewels and the interconnect. Rebuilt as a living, cross-team risk register mapped to MITRE FiGHT and ranked by likelihood × impact, it reprioritized the security roadmap toward UDM/NRF hardening and SEPP filtering — and became the input to the SOC's detection use cases and the annual audit. A threat model written from one vantage point defends one vantage point; the whole surface needs the whole org.

Chapter Summary

? Review Questions

  1. Name the eight threat-model branches and one headline threat for each.
  2. Why must a threat model be tailored to the actors a network faces?
  3. Which threats typically sit in the high-impact corner, and why are they often missed?
  4. How does OAuth contain SBA lateral movement?
  5. Why are insider and supply-chain threats the hardest to defend?
  6. What does mapping to MITRE FiGHT give an operator?
  7. How should a risk matrix drive defense prioritization?
  8. A threat model lists only radio attacks. What's wrong and how do you fix it?
🧪 Mini lab — build your risk register

On paper, build a top-10 5G risk register for a chosen network (e.g., a hospital private 5G, or a national consumer network): (1) For each of the eight branches, list the most relevant threat. (2) Score each by likelihood and impact (1–5) and rank. (3) Assign a primary control and the chapter that covers it. (4) Identify which actors drive your top three. (5) Map each to a MITRE FiGHT tactic. The result is the single most useful security artifact you can hand to a SOC (Chapter 27) and an auditor (Chapter 28) — and it's the lens for the rest of Part 6.