Approfondimento Tech

Cyber-sicurezza 5G/6G autonome

Sicurezza 5G/6G, network slicing ed edge computing: rischi, difese zero-trust, codice di esempio e roadmap per CISO e telco.

Cyber-sicurezza

27 Gennaio 2026

Indice dei contenuti

  • Dal 4G al 6G: architetture e differenze che contano per la sicurezza
  • Reti autonome: intent-based, self-organizing e dove si nascondono i rischi
  • Superfici d’attacco emergenti: edge, IoT massivo, slicing e MITM “nei corridoi”
  • Difese pratiche: Zero Trust per mobile, segmentazione e anomaly detection
  • Laboratorio: due slice, un attacco e tre contromisure
  • Autenticazione forte e protezione identità: UE, device, funzioni di rete
  • Compliance e governance: telco, fornitori e pubblico/privato
  • Roadmap operativa per CISO e architetti
  • Dalla “connettività remota” all’architettura d’impresa: cambio di paradigma
  • Caso d’uso: manufatturiero con slice URLLC e eMBB

Dal 4G al 5G/6G cambia tutto: SBA, edge, Open RAN, network slicing e reti autonome spostano la sicurezza su API, identity workload e isolamento dei slice. Qui spieghiamo rischi, Zero Trust, anomaly detection e forniamo codice per simulare attacchi e contromisure.

Le reti mobili di nuova generazione non sono solo “più veloci”: sono più software-defined, distribuite e autonome. Il salto dal 4G al 5G e, a breve, al 6G, introduce Service-Based Architecture (SBA), network function cloud-native, Open RAN, edge computing (MEC) e, soprattutto, network slicing, cioè la possibilità di ritagliare “reti virtuali” con requisiti diversi su un’unica infrastruttura fisica. Questa potenza espande anche la superficie d’attacco: IoT massivo(mMTC), traffico URLLC mission-critical, API esposte in core e edge, dispositivi con zero-touch provisioning, orchestratori che automatizzano tutto (e quindi possono automatizzare anche gli errori).


In questo articolo pensato per CISO, team SOC, architetti telco cloud e responsabili OT/IoT analizziamo (in modo operativo) cosa cambia, quali minacce emergono e quali mitigazioni applicare: segmentazione, autenticazione forte, rilevamento delle anomalie, Zero Trust per reti mobili, hardening delle API SBA e isolamento rigoroso dei slice. Troverai anche esempi pratici (in Python, Bash e Kubernetes YAML) per simulare un network slice, iniettare un attacco, rilevarlo e mitigarlo.

Parole chiave utilizzate (in evidenza nell’articolo): 5G, 6G, network slicing, edge computing, MEC, Open RAN, SBA, UPF, gNB, IoT, mMTC, URLLC, eMBB, Zero Trust, man-in-the-middle, MITM, autenticazione forte, segmentazione di rete, rete autonoma, AI/ML, SDN, NFV, telco cloud, API, orchestrazione, NIS2, CRA, NESAS, SCAS.

Dal 4G al 6G: architetture e differenze che contano per la sicurezza

Il 4G ha introdotto la virtualizzazione (NFV) ma con un core relativamente centralizzato. Il 5G accelera:

  • Core cloud-native a microservizi (SBA) con interfacce API (tipicamente HTTP/2 + TLS) tra funzioni come AMF, SMF, UPF, PCF, AUSF, ecc. La sicurezza non è più solo “diameter/IPsec”: è mTLS, gestione certificati, API gateway, rate-limit, authz fine-grained.
  • Separazione forte controllo/dati (CUPS): l’UPF vicino all’edge accorcia la latenza ma espone punti d’ispezione e policy sul piano dati in sedi distribuite.
  • Open RAN: disaccoppia componenti RAN (RU/DU/CU) con interfacce aperte. Vantaggi per l’innovazione, ma nuove superfici: supply chain, controller RIC (near-RT/non-RT) e xApps/rApps da validare.
  • Edge computing / MEC: funzioni core e applicazioni verticali (es. robotica, OT) si spostano in edge cloud. Security posture da data center “pulito” a “punto vendita” distribuito: fisicamente accessibile, spesso multi-tenant.
  • Network slicing: slice logici (eMBB, URLLC, mMTC, verticali OT) con isolamento di risorse e SLA dedicati. L’isolamento diventa requisito di sicurezza, non solo di QoS.

Verso 6G, i temi si amplificano: rete autonoma (autonomic/intent-based), AI/ML per controllo e difesa, sensing integrato, RIS (Reconfigurable Intelligent Surfaces), integrazione non-terrestre (NTN).

Esempio
Ciascuno aggiunge vettori d’attacco, compromissione dei modelli di AI che governano il closed-loop.

Implicazione pratica: la sicurezza passa da “perimetro + APN” a security-by-design nella SBA, hardening API, Zero Trust a ogni hop, telemetria ricca e controlli policy-driven sul piano dati (UPF) e di controllo (AMF/SMF).

Reti autonome: intent-based, self-organizing e dove si nascondono i rischi

Le reti autonome promettono self-configuration, self-optimization e self-healing su base AI/ML. L’operatore o l’azienda esprime un intent (“garantire 5 ms di latenza a questo slice URLLC”) e l’orchestratore realizza policy, scaling e percorsi ottimali.

Punti critici di sicurezza:

  • Orchestratori e controller (core, RAN, RIC) diventano “cervelli” ad alto privilegio. Un MITM o una compromissione su questi piani può propagarsi in pochi secondi su migliaia di edge.
  • Modelli AI/ML: data poisoning, model stealing, drift non rilevato ⇒ decisioni errate su slicing, routing, QoS, ammissione UE.
  • Zero-touch provisioning dei device e delle site edge: supply chain, credenziali bootstrap, PKI.
  • API “northbound/southbound” verso OSS/BSS, partner e terze parti: più ecosistema, più superfici.

Contromossa: governance di modelli e dati, attestazione hardware (TPM, TEE), firma delle xApps/rApps, policy guardrails (limiti d’azione per l’automazione), canary slice per testare cambi di configurazione prima del rollout.

Superfici d’attacco emergenti: edge, IoT massivo, slicing e MITM “nei corridoi”

Nel 5G l’attaccante non deve più “sfondare il core”: può colpire ai margini, dove l’infrastruttura è più distribuita e multi-tenant.

  • Edge/MEC
    • Accesso fisico e side-channel (USB, console, boot).
    • Multi-tenancy tra workload di terze parti e funzioni telco.
    • Dati telemetrici e PII che transitano localmente per ridurre latenza.
  • IoT massivo / mMTC
    • Dispositivi low-cost con autenticazione debole, firmware non aggiornati.
    • Zero-touch mal configurato = credenziali esposte e pivot verso l’edge.
    • DoS distribuiti “dall’interno” del slice.
  • Network slicing
    • Isolamento logico incompleto (policy errate su UPF/SMF, namespace condivisi in Kubernetes, SDN non vincolate).
    • MITM intra-slice: attore malevolo si inserisce “nel corridoio” dello slice (proxy, service mesh compromessa, ARP/NDP spoof in domini L2/L3 di MEC).
    • Noisy neighbor: saturazione risorse condivise che degrada URLLC o esfiltra dati via timing side-channel.
  • Open RAN
    • RIC e xApps non verificate → manipolazione scheduling, power control, handover.
    • Interfacce O-Fronthaul e midhaul: cifratura, autenticazione dei componenti gNB (RU/DU/CU).
  • SBA / API
    • API esposte senza mTLS, JWT e autorizzazioni “least-privilege”.
    • Rate-limit assente → DoS di segnaling (registrazioni UE, sessioni PDU).
    • Logging insufficiente → impossibile threat hunting.

Difese pratiche: Zero Trust per mobile, segmentazione e anomaly detection

Zero Trust in ambito 5G/6G significa: “mai fidarsi, verificare sempre”, anche tra funzioni di rete, slice, edge e applicazioni verticali.

Piano di controllo (SBA):

  • mTLS obbligatorio tra NFs con PKI interna robusta, cert rotation automatica e short-lived certs.
  • API gateway con authn/authz (OPA/Rego), rate-limit, schema validation, WAF per payload JSON.
  • Segregazione tra domini (core vs edge) e tra slice a livello di routing, service mesh (mTLS SPIFFE/SPIRE), namespace.

Piano dati (UPF):

  • Policy per slice (SDF templates) e micro-segmentazione fino al flow (5-tuple + DSCP/QFI).
  • Ispezione selettiva (mirroring N3/N9) verso sonde IDS/IPS compatibili 5G; eBPF/XDP per telemetria low-overhead.
  • Rate policing e protezione contro flood intra-slice.

Edge/MEC e Kubernetes:

  • NetworkPolicy “deny-all by default”, RBAC minimale, PSP/PodSecurity (o Pod Security Standards), immagini firmate, attestazione noder/VM.
  • Secrets in KMS/HSM, TOTP o FIDO2 per accessi umani, SSH disabilitato dove possibile.
  • Runtime policy (Falco/eBPF) per processi anomali.

IoT / mMTC:

  • Autenticazione forte (EAP-TLS, DTLS, certificati device), SUCI per privacy SUPI, attestate il firmware, SBOM.
  • Fleet management con patching, inventory e revoca credenziali.
  • Gateway con mTLS verso l’edge, QoS e rate-limit per evitare “tempeste” di telemetria.

Anomaly detection:

  • Feature a più strati: segnaling (registrazioni UE, SM/AM), piano dati (flow e QFI), RAN KPIs (handover failure, PRB usage), edge (syscalls via eBPF).
  • Modelli unsupervised (Isolation Forest, z-score, autoencoder) con explainability minima (feature importance) per uso SOC.

Laboratorio: due slice, un attacco e tre contromisure

Di seguito un esempio pratico per creare un ambiente di test MEC con due “slice applicativi” isolati a livello Kubernetes (due namespace) e una service mesh con mTLS. Poi inietteremo un semplice MITM/proxy e mostreremo come rilevarlo e bloccarlo con NetworkPolicy e controllo OPA.

Esempi
Non replica in toto una core 5G, ma i pattern di isolamento, telemetria e mitigazione sono trasferibili.

1) Definizione dei due slice (namespace + label)

# Slice eMBB “video-analytics”
kubectl create ns slice-embb
kubectl label ns slice-embb slice=embb env=lab

# Slice URLLC “robotics-control”
kubectl create ns slice-urllc
kubectl label ns slice-urllc slice=urllc env=lab

2) Politiche di rete: deny-all e allow solo intra-slice

# base-deny.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: slice-embb
spec:
  podSelector: {}
  policyTypes: ["Ingress","Egress"]

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: slice-urllc
spec:
  podSelector: {}
  policyTypes: ["Ingress","Egress"]

# allow-intra-slice.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-intra-slice
  namespace: slice-embb
spec:
  podSelector: {}
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              slice: embb
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              slice: embb
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-intra-slice
  namespace: slice-urllc
spec:
  podSelector: {}
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              slice: urllc
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              slice: urllc

Applichiamo:
kubectl apply -f base-deny.yaml
kubectl apply -f allow-intra-slice.yaml

3) Service mesh con mTLS e identità SPIFFE

Con Istio (o Linkerd) abilita mTLS strict a livello di namespace:

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: mtls-strict
  namespace: slice-embb
spec:
  mtls:
    mode: STRICT
---
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: mtls-strict
  namespace: slice-urllc
spec:
  mtls:
    mode: STRICT

Con Authorization Policy separa ulteriormente i service account per ruolo.

4) Un “attacco” semplice: proxy malevolo che tenta di ponticellare i slice

Creiamo un Pod “attacker” nel namespace slice-embb che prova a chiamare servizi nel namespace slice-urllc:

apiVersion: v1
kind: Pod
metadata:
  name: attacker
  namespace: slice-embb
spec:
  containers:
    - name: curl
      image: curlimages/curl:8.8.0
      command: ["sleep","infinity"]

Testiamo (dovrebbe fallire grazie alle NetworkPolicy):

kubectl exec -n slice-embb attacker -- \
  curl -sS http://svc-urllc.slice-urllc.svc.cluster.local:8080/health
# Atteso: timeout / connection refused

Se qualcuno rimuove/ammorbidisce le policy o la mesh, la chiamata potrebbe passare: è il nostro “MITM intra-slice” di laboratorio.

5) Telemetria e anomaly detection (Python)

Supponiamo di esportare (via eBPF o mesh metrics) conteggi di chiamate cross-namespace. Un semplice z-score può evidenziare deviazioni:

import numpy as np

# media storica (chiamate cross-slice per minuto)
baseline = np.array([0,0,0,1,0,0,0,1,0,0,0,0,1,0,0], dtype=float)
mu, sigma = baseline.mean(), baseline.std(ddof=1) or 1.0

# finestra corrente (con attacco)
current = np.array([0,0,0,5,6,7,8,9,10], dtype=float)

z_scores = (current - mu) / sigma
threshold = 3.0
anomalies = np.where(z_scores > threshold)[0]

print("mu=%.2f sigma=%.2f" % (mu, sigma))
print("z-scores:", np.round(z_scores,2))
print("anomaly indices:", anomalies.tolist())

Azioni automatiche (SOAR): se anomalies non è vuoto → blocca route cross-slice (riapplica NetworkPolicy), quarantenaPod attacker, apri ticket al SOC e crea PCAP mirato.

6) Blocco immediato via NetworkPolicy “tagliacavi”

In scenari reali useresti un controller GitOps o un playbook SOAR. Qui uno snippet d’urgenza:

# Isola totalmente il namespace colpito
kubectl label ns slice-embb quarantine=true --overwrite

cat <<'YAML' | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: quarantine-all
  namespace: slice-embb
spec:
  podSelector: {}
  policyTypes: ["Ingress","Egress"]
  ingress: []   # blocco totale
  egress: []    # blocco totale
YAML

7) Controllo OPA/Envoy sulle API SBA

Per funzioni SBA (o servizi edge), inserisci OPA come ext_authz di Envoy. Esempio di policy Rego (banale) che vieta cross-slice:

package sba.authz

default allow = false

# Consenti solo se il token (claim 'slice') corrisponde al namespace di destinazione
allow {
  input.parsed_token.claims.slice == input.request.http.headers["x-dest-namespace"]
}

Con questa logica, anche se le NetworkPolicy venissero temporaneamente indebolite, l’API gateway bloccherebbe richieste illegittime.

Autenticazione forte

Autenticazione forte e protezione identità: UE, device, funzioni di rete

5G AKA e SUCI migliorano privacy/identity dei UE. Ma nell’edge e tra NFs serve ulteriore rigore:

  • mTLS con SPIFFE IDs (“spiffe://telco.local/ns/slice-urllc/sa/robotics-controller”).
  • Rotazione automatica dei segreti, workload identity (senza secret statici).
  • Per IoT, preferisci EAP-TLS/DTLS con certificati univoci device (enrollment in factory + attestazione a primo boot zero-touch).
  • JTI (JWT ID) per prevenire replay, audience ristretta, short TTL.
  • AUSF/UDM hardening: accesso least-privilege, HSM per chiavi master.

Open RAN e RIC: come frenare xApps “creative”

  • Supply chain
    Firma e verifica xApps/rApps, SBOM, scanning CVE a build-time.
  • Sandbox
    Esegui xApps in ambienti con quote/limiti e policy guardrails (scope massimo del loro impatto).
  • Kill switch
    Abilita rollback e disattivazione rapida di una xApp difettosa.
  • Monitoraggio
    KPI RAN anomali (handover, PRB, BLER) mappati alle xApps responsabili (observability by design).

Compliance e governance: telco, fornitori e pubblico/privato

Il mosaico normativo tocca telco e imprese che adottano 5G privati:

  • NIS2
    Obblighi di risk management, incident reporting, supply chain; ruoli chiari (CISO vs Operations) e sanzioni per inadempienze.
  • Cyber Resilience Act (CRA)
    Responsabilità sui prodotti digitali (inclusi device IoT e software per edge), patching tempestivo, vulnerabilità disclosure.
  • GSMA NESAS/3GPP SCAS
    Schemi di sicurezza per NFs e apparati RAN.
  • ETSI MEC
    Linee guida per sicurezza dei servizi edge.
  • Data governance & sovranità
    Dove risiede il dato (edge, core, cloud pubblico), logging a prova di audit, retention per verticale (sanità, industria).

Collaborazione pubblico/privato: condivisione IoC, CTI verticale (energia, sanità, manifattura), esercitazioni congiunte tabletop su scenari URLLC/OT (ad es. robotica ferma per attacco su slice).

Roadmap operativa per CISO e architetti

0–30 giorni (Assessment e “guardrail” minimi)

  • Mappa asset: NFs, edge sites, UPF, gNB, RIC, IoT.
  • Verifica mTLS obbligatorio su tutte le API SBA; abilita rate-limit e schema validation.
  • Imposta NetworkPolicy “deny-all by default” e mTLS mesh sui namespace per slice.
  • Accendi telemetria (flow, segnaling, eBPF), centralizza i log (SIEM).
  • Introduci playbook SOAR di quarantena slice/namespace e rotazione credenziali edge.

30–90 giorni (Isolamento, identity e detection)

  • SPIFFE/SPIRE per identity workload, OPA davanti alle API critiche.
  • Fleet IoT: enrollment certificati, EAP-TLS, SBOM e patch policy.
  • Model governance per automazioni (dataset, drift monitor).
  • Baseline di traffico per slice e modelli unsupervised (Isolation Forest / z-score) con alert “explainable”.

3–12 mesi (Resilienza e prove di realtà)

  • Red team su edge/MEC e RIC; fuzzing su API SBA.
  • Chaos engineering per reti autonome (fault controllato, verifica roll-back automatico).
  • Supply chain: firma immagini/container, SLSA livello 2–3, verifiche SBOM.
  • Accordi SLA che includano metriche di security isolation tra slice (non solo latenza e throughput).

Dalla “connettività remota” all’architettura d’impresa: cambio di paradigma

Per molte imprese, il mobile è stato a lungo sinonimo di accesso remoto (APN, VPN). Con 5G/6G, diventa parte dell’architettura applicativa: edge analytics, OT connessa, veicoli/autonomi, realtà aumentata in fabbrica. Di conseguenza:

  • La sicurezza mobile deve integrarsi con IAM, DevSecOps, data governance e OT security.
  • Gli SLA tra IT/OT/Telco includono criteri di isolation e forensics.
  • Il SOC deve “parlare 5G”: segnaling, QFI, SMF/UPF logs, RAN KPIs.
  • La business continuity considera gli edge come mini-data center: scorte, spare parts, remote wipe, fallback 4G/5G.

Esempi aggiuntivi di codice e configurazioni

Ispezione selettiva del traffico (iptables/eBPF mirroring)

Nota: in produzione preferisci sonde e broker di telemetria nativi. Qui un’idea minima.

# Mirroring delle connessioni verso il servizio critico dello slice URLLC
IF=edge0
MON=10.10.10.50 # sonda IDS
sudo iptables -t mangle -A PREROUTING -i $IF -p tcp --dport 443 \
  -j TEE --gateway $MON

Rilevamento semplificato di “noisy neighbor” (Python)

import numpy as np

# Utilizzo CPU/latency slice (percentili) per 2 slice
embb = np.array([50,52,49,51,80,85,90,88,87])    # spike sospetto
urllc = np.array([10,11,9,10,10,11,9,10,10])

def spike_idx(x, win=4, k=3.5):
    m = np.convolve(x, np.ones(win)/win, mode='valid')
    s = np.sqrt(np.convolve((x[:len(m)]-m)**2, np.ones(1), mode='same') + 1e-6)
    z = (x[:len(m)]-m)/ (s + 1e-3)
    return np.where(z>k)[0]

print("embb spikes:", spike_idx(embb).tolist())
print("urllc spikes:", spike_idx(urllc).tolist())

Hardening API SBA (Envoy filter snippet)

# Envoy: rate limit + header constraints per API SBA
http_filters:
- name: envoy.filters.http.ratelimit
  typed_config:
    "@type": type.googleapis.com/envoy.extensions.filters.http.ratelimit.v3.RateLimit
    domain: sba-nf
    timeout: 0.1s
- name: envoy.filters.http.header_to_metadata
  typed_config:
    "@type": type.googleapis.com/envoy.extensions.filters.http.header_to_metadata.v3.Config
    request_rules:
      - header: x-slice
        on_header_present:
          metadata_namespace: envoy.lb
          key: slice
          value: "%REQ(x-slice)%"
        on_header_missing:
          value: "unknown"

Policy Gate su CI/CD (GitHub Actions) per xApps/RAN

- name: Run SBOM scan
  uses: anchore/scan-action@v3
  with:
    path: .
- name: OPA Policy Gate
  uses: open-policy-agent/setup-opa@v3
- run: |
    opa eval --format=pretty \
      -i artifact.json -d policies rego.allow

Caso d’uso: manufatturiero con slice URLLC e eMBB

Un’azienda automotive adotta un 5G privato. Due slice:

  • URLLC per robotica (5 ms, jitter minimo, edge locale, Zero Trust end-to-end).
  • eMBB per video analytics e AR (alto throughput, buffering tollerabile).

Rischio osservato: durante uno sprint, un team abilita temporaneamente un proxy per test AR e, involontariamente, apre rotte cross-slice. I robot registrano micro-interruzioni (jitter).
Rimedi applicati:

  • NetworkPolicy deny-all + mTLS mesh con SPIFFE.
  • OPA su gateway SBA e servizi edge.
  • Anomaly detection su jitter e cross-namespace calls con playbook SOAR di quarantena automatica.
    Risultato: l’incidente successivo viene rilevato in 30 secondi e contenuto in <1 minuto; nessun fermo linea.

Conclusioni

Il passaggio a 5G/6G e a reti autonome non è un semplice upgrade di throughput: è una trasformazione architetturale e organizzativa. Network slicing, edge computing, Open RAN e SBA portano flessibilità ma anche nuove minacce: MITM intra-slice, supply chain xApps, API esposte, IoT massivo. La risposta vincente combina Zero Trust, segmentazione puntuale del piano dati, autenticazione forte per device e NFs, hardening delle API e anomaly detection con telemetria profonda.

Per CISO e operatori telco cloud, la sicurezza mobile non è più “accesso remoto”, ma componente nativa dell’architettura d’impresa, intrecciata con DevSecOps, OT security e governance dei dati. Adottare subito controlli guardrail, telemetria e automazione sicura consente di scalare l’innovazione senza spalancare la porta agli attaccanti.

Domande e risposte

  1. Che cos’è il network slicing in poche parole?
    È la creazione di slice logici reti “virtuali” con risorse, policy e SLA dedicati che convivono sulla stessa infrastruttura 5G/6G. Ogni slice è isolato e ottimizzato per un caso d’uso (eMBB, URLLC, mMTC, verticale industriale).
  2. Perché il 5G è più esposto del 4G?
    Perché introduce SBA a microservizi con API web, edge/MEC distribuiti e Open RAN. Crescono i punti di ingresso e serve Zero Trust a ogni hop.
  3. Qual è l’attacco più sottovalutato?
    Il man-in-the-middle intra-slice o “cross-slice” tramite configurazioni errate (mesh, NetworkPolicy, UPF). Non fa rumore ma degrada URLLC e apre canali d’esfiltrazione.
  4. Come si applica lo Zero Trust a una rete mobile?
    mTLS ovunque, identity workload (es. SPIFFE), authz con OPA, deny-all predefinito, micro-segmentazione sul piano dati (UPF) e service mesh; validazione API SBA e rate-limit.
  5. Edge/MEC: quali priorità di difesa?
    Hardening fisico e logico, immagini firmate, attestazione del nodo, KMS/HSM per segreti, Network Policy restrittive, telemetria eBPF e isolamento dei tenant.
  6. Come proteggere milioni di dispositivi IoT?
    Autenticazione forte (EAP-TLS/DTLS), gestione certificati e revoca, SBOM e patch, gateway con mTLS e rate-limit, rilevamento anomalie nel comportamento.
  7. Open RAN è più rischioso?
    È più aperto, quindi richiede governance severa: firma/verifica xApps/rApps, sandbox e kill switch, RIC protetto e continui test di regressione.
  8. Quale telemetria serve al SOC?
    Eventi SBA (AMF/SMF/PCF), QFI/5-tuple dal piano dati, RAN KPIs, eBPF su edge, API metrics (latency, error rate). Senza telemetria, niente anomaly detection affidabile.
  9. Quali norme guardare in Europa?
    NIS2 per risk & incident management, Cyber Resilience Act per prodotti/patching, schemi GSMA NESAS/3GPP SCAS, linee ETSI MEC per l’edge.
  10. Un primo passo concreto per un’azienda non telco?
    Se usi (o userai) 5G privato: definisci slice per funzione critica, imposta deny-all + mTLS + OPA; integra la telemetria nel tuo SIEM e scrivi un playbook SOAR di quarantena slice.
1
To top