A powerful detection aid — and a new attack surface of its own
"Machine learning is excellent at finding the anomaly you didn't write a rule for — and excellent at confidently flagging the wrong thing. Use it as a sense, not a judge."
— THE ML-IN-SECURITY BALANCE
5G generates more signaling telemetry than any human can watch. Machine learning helps — spotting anomalies in authentication, signaling, and API behavior that no static rule anticipated. NWDAF brings analytics natively into the architecture. But ML is not magic: it produces false positives, can be attacked (poisoning, evasion), and must stay a decision aid, not an unaccountable judge. This chapter covers where ML fits, where NWDAF helps, and the risks.
🎯 Learning objectives
Identify where ML fits in the 5G security loop (detection, not enforcement).
Apply ML to signaling, authentication, and API anomalies.
Use NWDAF for security analytics.
Understand adversarial ML risks and governance.
📘 Standards reference box — Chapter 31
Reference
Title
Note
TS 23.288
NWDAF — network data analytics
Rel-18/19 edition
TR 33.8xx
AI/ML security studies (SA3)
Rel-18/19 (verify)
NIST AI RMF
AI risk management framework
current
Checked June 2026 — Rel-18/19 AIML security evolving; verify against the latest 3GPP version.
31.1 Where ML Fits
FIGURE 31.1Where ML Fits — Detection, Not Enforcement
Purpose: the safe placement of ML. It surfaces anomalies a rule would miss; humans and playbooks judge and act. Wiring ML straight to enforcement risks automated false-positive damage.
FIGURE 31.2Signaling Anomaly Detection Pipeline
Purpose: ML's home turf. Signaling anomaly detection catches novel patterns (a new storm or recon shape) that static rules (Chapter 26) would miss.
FIGURE 31.3Authentication Anomaly Model — Features and Signals
Purpose: ML on authentication. Combining failure-cause mix, geo/time clustering, and identity anomalies, a model can flag a false base station or credential abuse earlier than a fixed threshold.
FIGURE 31.4API Abuse Detection Architecture
Purpose: ML on exposure. A per-AF behavioral baseline flags the entitled-but-abusive pattern (Chapter 12) — like a partner whose calls drift into surveillance — that a fixed quota might not catch.
FIGURE 31.5NWDAF Analytics for Security
Purpose: the in-network analytics function. NWDAF provides standardized analytics — including abnormal-behavior detection — that security can consume, complementing an external SIEM (Chapter 26).
FIGURE 31.6Adversarial ML — Poisoning and Evasion
Purpose: ML is itself attackable. Poisoning builds blind spots; evasion stays under thresholds — which is why ML must complement (not replace) rules, and why model security matters.
FIGURE 31.7Human-in-the-Loop Triage Design
Purpose: the responsible design. Analysts confirm or dismiss ML candidates and their decisions retrain the model — keeping a human accountable and improving accuracy over time.
FIGURE 31.8AI Governance Checklist for Telecom Security
Purpose: AI in security needs its own governance. Provenance, ensembles, human oversight, explainability, and adversarial testing keep ML a trustworthy aid rather than an unaccountable risk.
31.2 The Practical Operator View
Use ML for detection, not enforcement — surface candidates, let humans/playbooks act.
Ensemble ML with rules — each covers the other's blind spots; never make ML the sole judge.
Leverage NWDAF for native analytics, complementing the SIEM.
Govern the models — provenance, drift monitoring, adversarial testing, explainability.
Keep a human in the loop for enforcement decisions and to retrain from confirmations.
31.3 Threats and Mitigations
Threat
Vector
Defense
Model poisoning
corrupted training data
data provenance/validation
Evasion (low-and-slow)
traffic shaped under threshold
ensembles, rules+ML, retrain
Automated FP damage
ML wired to enforcement
human-in-the-loop
Model drift
changing baselines
drift monitoring, retraining
Privacy/regulatory
training on sensitive data
governance, minimization (Ch19)
31.4 Terminology
Term
Meaning
NWDAF
Network Data Analytics Function (3GPP-native analytics)
poisoning / evasion
Corrupting training data / shaping inputs to avoid detection
human-in-the-loop
Human confirms ML decisions before action
drift
Model accuracy degrading as conditions change
Real network example. An operator deployed an ML anomaly detector on signaling and, impressed by early results, wired it directly to an automated mitigation that throttled "anomalous" sources. During a major sporting event, the legitimate, never-before-seen traffic pattern of tens of thousands of fans triggered the model, and the automation throttled real subscribers at the worst possible time — an automated false-positive outage. The fix wasn't to abandon ML but to put a human in the loop: the model now surfaces ranked candidates to the SOC (Chapter 27), analysts confirm before any throttling, and the event's pattern was added to training. ML is a superb sense and a dangerous sole judge — keep it advisory, keep a human accountable.
★ Chapter Summary
ML excels at detecting novel anomalies in signaling, auth, and API behavior that rules miss — but as a sense, not a judge.
NWDAF brings 3GPP-native analytics (including abnormal behavior) usable for security, complementing the SIEM.
ML is attackable: poisoning builds blind spots, evasion stays under thresholds — ensemble with rules.
Keep a human in the loop for enforcement; retrain from confirmations.
Govern models: provenance, explainability, drift monitoring, adversarial testing, privacy alignment.
? Review Questions
Why should ML aid detection rather than drive enforcement directly?
Where does ML add the most value over static rules?
What is NWDAF and how does it support security analytics?
Explain poisoning and evasion attacks on security ML.
Why ensemble ML with rules?
What is the role of human-in-the-loop triage?
Name four AI governance controls for telecom security ML.
An ML detector wired to auto-mitigation causes an outage during an event. Diagnose and fix.
🧪 Mini lab — anomaly detection, responsibly
Using captured/simulated 5G signaling data: (1) Build a simple baseline of "normal" registration/auth rates per cell/time. (2) Add an anomaly score for deviations and test it on an injected signaling storm — does it flag the storm? (3) Now inject a benign but unusual pattern (e.g., an event surge) and observe the false positive. (4) Design the human-in-the-loop: how would an analyst confirm before any action, and how would the event pattern be fed back to retrain? (5) List two ways an attacker could evade your detector (low-and-slow) and how an ensemble with a rule would catch it. You've now experienced both ML's power and its failure mode — and the governance that makes it safe to use.