Mobility Security Assessment Threat Model
Mobility Security Assessment Threat Model
This threat model is written for authorized assessment and test planning, not for opportunistic attack execution. Its job is to help you map access, trust boundaries, impact, and evidence requirements across a mobile environment.
Assessment framing
Use this model to answer four questions:
- What trust boundary am I crossing?
- What level of access is required?
- What failure would matter operationally?
- What evidence would prove the control is working or failing?
Primary trust zones
| Zone | What it contains | Typical risks |
|---|---|---|
| Subscriber edge | UE, SIM/eSIM, carrier apps, local telephony interfaces | Privacy exposure, weak local controls, provisioning abuse |
| RAN and site edge | Air interface, antenna site, timing, DU/CU or eNB/gNB edge | Downgrade risk, physical exposure, site management weakness |
| Transport | Fronthaul, midhaul, backhaul, timing distribution, OOB paths | Segmentation failure, sync weakness, management-plane bleed |
| Core control plane | MME/AMF, HSS/UDM, AUSF, SMF, PCRF/PCF, NRF | Auth, discovery, policy, and signaling trust failure |
| Core user plane | SGW/PGW, UPF, GTP-U, N6 breakout, MEC | Session abuse, traffic redirection, tenant isolation failure |
| Management and cloud | OSS/BSS, EMS/NMS, IAM, Kubernetes, CI/CD, vendor access | Privilege concentration, secret leakage, remote-admin abuse |
| Interconnect | SS7, Diameter, SEPP, IPX/GRX, roaming gateways | Partner trust failure, signaling abuse, cross-operator pivot risk |
Threat categories to test
| Category | Mobility interpretation | Example assessment questions |
|---|---|---|
| Spoofing | False peer, identity, NF, or subscriber context | Can an unauthorized peer be treated as legitimate? |
| Tampering | State, policy, session, or routing changes | Can signaling or policy be altered outside approved paths? |
| Repudiation | Weak attribution of admin or protocol events | Would you know who triggered a critical change? |
| Information disclosure | Identity, subscriber, topology, or policy leakage | Can sensitive data be enumerated or inferred too broadly? |
| Denial of service | Control-plane, radio, timing, or session exhaustion | What breaks first, and how quickly is it detected? |
| Elevation of privilege | Access moving from subscriber or partner to core/admin | Can a narrow role pivot into broad telecom control? |
Access model
| Access level | Description | Typical examples |
|---|---|---|
| AL0 | Public/external view | OSINT, exposed portals, passive internet review |
| AL1 | Subscriber-side access | Test handset, test SIM, passive cell measurements |
| AL2 | Authorized physical site access | Cabinet review, local console, power/timing inspection |
| AL3 | Internal read-only ops access | Inventory, diagrams, SPAN/TAP, read-only OSS/NMS |
| AL4 | Lab or pre-prod admin access | Open5GS, simulator stacks, controlled config changes |
| AL5 | Cloud/platform admin access | Kubernetes, IAM, secrets, registry, CI/CD |
| AL6 | Interconnect authority | Roaming, SEPP, Diameter gateway, partner trust review |
What to document for each finding
Every finding should include:
- Trust boundary crossed
- Required access level
- Observed behavior
- Expected behavior
- Operational impact
- Detection or logging status
- Recommended mitigation or follow-up test
Where to go next
- 0. Methodology for execution order
- Theory_Macro_Overall for the document map
- open5gs_lab/18_test_plan_mobility_site_to_core for the site-to-core assessment view