Security assurance e controlli di sicurezza nelle infrastrutture 5G

Security assurance e 5G rappresentano due pilastri fondamentali per garantire la protezione e l’affidabilità delle moderne infrastrutture di telecomunicazione. Con il progressivo sviluppo della tecnologia 5G, queste reti sono diventate il fulcro di una società sempre più interconnessa, supportando applicazioni critiche che spaziano dalla sanità digitale all’industria 4.0.

Tuttavia, la crescente complessità tecnologica e la molteplicità degli attori coinvolti rendono la sicurezza un obiettivo tanto indispensabile quanto difficile da raggiungere. Questo articolo esplora le sfide e le soluzioni legate alla security assurance nelle reti 5G, con un focus sui controlli di sicurezza necessari per proteggere componenti e funzioni chiave, evidenziando l’importanza di standard come le Security Assurance Specifications (SCAS) e di schemi di certificazione come il NESAS, sviluppati per affrontare le vulnerabilità e mitigare i rischi delle configurazioni insicure.

Evoluzione delle Infrastrutture 5G: Sicurezza, Complessità e Sfide della Security Assurance

Negli ultimi decenni, i sistemi di comunicazione personale hanno subito trasformazioni profonde. Con l’avvento degli smartphone, l’integrazione tra telefonia mobile e comunicazione dati ha rivoluzionato il nostro modo di interagire e vivere quotidianamente. Alla luce della crescente digitalizzazione, dell’incremento delle transazioni digitali, della condivisione di informazioni sensibili e, più in generale, della dipendenza della società e dell’economia da una connettività continua e affidabile, le infrastrutture 5G (e le relative evoluzioni verso il 6G) sono considerate parte dell’infrastruttura critica nazionale. È pertanto scontato affermare che la sicurezza sia una priorità per tali infrastrutture di telecomunicazioni.

Tuttavia, ciò che risulta decisamente meno scontato e semplice è, da un lato, riuscire a individuare, sviluppare e implementare soluzioni efficaci e innovative che possano realmente garantire la protezione delle infrastrutture e dei dati; dall’altro lato, identificare modalità concrete per verificare che i processi e le misure adottate soddisfino i requisiti di sicurezza definiti e proteggano effettivamente contro minacce, vulnerabilità e attacchi.

Per quanto riguarda il primo aspetto, ovvero l’identificazione di soluzioni adeguate ed efficaci, ci limitiamo, per motivi di spazio, a ricordare che il 3GPP (3rd Generation Partnership Project), ovvero il consorzio internazionale di standardizzazione che si occupa dello sviluppo di protocolli per le telecomunicazioni mobili, ha compiuto enormi progressi negli ultimi venticinque anni. Se, infatti, fino alla seconda generazione l’approccio alla sicurezza era quantomeno naïve (ad essere generosi), a partire dalla terza generazione, ovvero con l’inizio del nuovo millennio, l’approccio del 3GPP alla sicurezza è diventato finalmente ben più attento e sistematico.

Questo cambiamento è avvenuto grazie anche al coinvolgimento esplicito di crittografi ed esperti di sicurezza informatica, che hanno affiancato i tradizionali esperti di protocolli e tecnologie di telecomunicazione. Tale sinergia ha portato allo sviluppo di soluzioni che, pur rimanendo soggette a continui miglioramenti e alle sfide poste dalle minacce emergenti (impatto del quantum computing sugli attuali protocolli ed algoritmi crittografici, attacchi guidati e/o amplificati da intelligenza artificiale, minacce alla privacy amplificate dalla pervasività del sensing, etc.), possono oggi essere considerate ragionevolmente efficaci.

Tuttavia, anche le migliori soluzioni di sicurezza possono essere vanificate da errori di configurazione o sviste implementative. Pertanto, in questa sede, riteniamo maggiormente utile approfondire il secondo aspetto precedentemente citato, legato alla cosiddetta “Security Assurance”, ovvero alla capacità di dimostrare e verificare che i sistemi operino in modo sicuro, mantenendo l’integrità, la riservatezza e la disponibilità dei dati.

Nel contesto specifico delle infrastrutture 5G, la Security Assurance è ulteriormente complicata da (almeno!) tre aspetti peculiari, evidenziati graficamente nelle tre dimensioni della figura 1 (tratta da documenti ENISA). In primo luogo, le infrastrutture 5G sono caratterizzate da una maggiore complessità e eterogeneità tecnologica e funzionale rispetto alle generazioni precedenti, con l’integrazione di nuovi elementi come il Network Slicing, il Multi-access Edge Computing (MEC) e la virtualizzazione delle funzioni di rete (NFV).

Un secondo aspetto che incide significativamente sui processi di gestione della sicurezza è il coinvolgimento di numerosi attori. Se in passato le reti erano sviluppate e gestite da player specifici del settore TLC, gli attuali scenari evolutivi prevedono non solo la potenziale coesistenza di molteplici attori a livello operativo (verticali, cloud provider, infrastructure provider), ma anche la partecipazione di soggetti eterogenei nello sviluppo delle tecnologie, come l’integrazione di soluzioni open source sviluppate da terze parti, non sempre affidabili – come la cronaca recente tristemente insegna[1].

Infine, la sempre maggiore softwarizzazione delle funzioni di rete introduce un contesto simile a quello del software, con aggiornamenti continui dei sistemi, determinando un netto cambio di paradigma rispetto alle tradizionali soluzioni “statiche” di certificazione della sicurezza per componenti fisici (si pensi per esempio ai Common Criteria), soluzioni che appaiono evidentemente inadeguate rispetto alle esigenze di flessibilità e aggiornabilità delle soluzioni software adottate nei sistemi moderni.

Standardizzazione della Security Assurance in 5G: i test SCAS

Per affrontare in modo adeguato le problematiche legate alla verifica della sicurezza delle infrastrutture di rete 5G, il 3GPP ha avviato lo sviluppo di un insieme di specifiche denominate “Security Assurance Specifications” (SCAS). Tale iniziativa ha avuto inizio poco più di un decennio fa, con uno studio esplorativo[2] volto a definire una metodologia di security assurance per i componenti e le funzioni di rete standardizzate dal 3GPP.

Nella fase iniziale, durante la standardizzazione dell’LTE (ovvero la quarta generazione), furono sviluppate le prime tre specifiche SCAS, destinate a componenti di rete specifici e “fisici”, quali eNB, MME e PDN-GW. Tuttavia, con l’avvento del 5G e della sua architettura softwarizzata e orientata ai servizi, le specifiche SCAS si sono notevolmente ampliate, e sono state estese alla maggior parte delle funzioni di rete virtualizzate presenti nell’architettura core dei sistemi 5G.

Come infatti illustrato nella tabella seguente, aggiornata al settembre 2023, le specifiche SCAS coprono una decisamente ampia gamma di funzioni della rete 5G, includendo ben 20 Technical Specifications (TS), atte a descrivere in dettaglio gli specifici test di sicurezza da applicare alla funzione o componente in questione, e tre Rapporti Tecnici (TR) di carattere più generale e/o metodologico.

TS/TR	Nome della specifica
TS 33.116	Security Assurance Specification (SCAS) for the MME network product class
TS 33.216	Security Assurance Specification (SCAS) for the evolved Node B (eNB) network product class
TS 33.326	Security Assurance Specification (SCAS) for the Network Slice-Specific Authentication and Authorization Function (NSSAAF) network product class
TS 33.511	Security Assurance Specification (SCAS) for the next generation Node B (gNodeB) network product class
TS 33.512	5G Security Assurance Specification (SCAS); Access and Mobility management Function (AMF)
TS 33.513	5G Security Assurance Specification (SCAS); User Plane Function (UPF)
TS 33.514	5G Security Assurance Specification (SCAS) for the Unified Data Management (UDM) network product class
TS 33.515	5G Security Assurance Specification (SCAS) for the Session Management Function (SMF) network product class
TS 33.516	5G Security Assurance Specification (SCAS) for the Authentication Server Function (AUSF) network product class
TS 33.517	5G Security Assurance Specification (SCAS) for the Security Edge Protection Proxy (SEPP) network product class
TS 33.518	5G Security Assurance Specification (SCAS) for the Network Repository Function (NRF) network product class
TS 33.519	5G Security Assurance Specification (SCAS) for the Network Exposure Function (NEF) network product class
TS 33.520	5G Security Assurance Specification (SCAS); Non-3GPP InterWorking Function (N3IWF)
TS 33.521	5G Security Assurance Specification (SCAS);Network Data Analytics Function (NWDAF)
TS 33.522	5G Security Assurance Specification (SCAS); Service Communication Proxy (SCP)
TS 33.523	5G Security Assurance Specification (SCAS); Split gNB product classes
TS 33.527	Security Assurance Specification (SCAS) for 3GPP virtualized network products
TS 33.528	Security Assurance Specification (SCAS) for Policy Control Function (PCF)
TS 33.537	Security Assurance Specification (SCAS) for the Authentication and Key Management for Applications (AKMA) Anchor Function (AAnF)
TS 33.742	5G Security Assurance Specification (SCAS); Split gNB product classes
TR 33.818	Security Assurance Methodology (SECAM) and Security Assurance Specification (SCAS) for 3GPP virtualized network products
TR 33.926	Security Assurance Specification (SCAS) threats and critical assets in 3GPP network product classes
TR 33.927	Security Assurance Specification (SCAS); threats and critical assets in 3GPP virtualized network product classes

I test SCAS descrivono, per ogni funzione di rete, un determinato numero di valutazioni specificatamente progettate per riprodurre specifici “corner cases” che potrebbero essere sfruttati da un potenziale attaccante in caso di implementazioni non accurate o configurazioni errate.

Nello specifico, tali test sono finalizzati a verificare concretamente l’assenza di ambiguità implementative che potrebbero portare a vulnerabilità di sicurezza rilevanti, quali l’accesso non autorizzato, l’isolamento inadeguato delle funzioni, lo sfruttamento di messaggi di segnalazione contrastanti per bypassare meccanismi di protezione, e altre criticità di sicurezza. Pur differenziandosi in base alla specifica funzione 5G oggetto della valutazione, i test SCAS condividono l’obiettivo comune di assicurare che le funzioni di rete non introducano, nelle loro implementazioni e/o configurazioni, rischi significativi per la sicurezza.

Un aspetto tecnico che rende particolarmente complessi un sottoinsieme non marginale di test SCAS è la necessità di coordinare simultaneamente le risposte di più funzioni di rete. Per fare un esempio concreto, la maggior parte dei test relativi alla funzione di rete AMF (Access and Mobility Function, peraltro funzione cruciale in termini di sicurezza 5G poiché rappresenta il punto di accesso dell’utente alla rete core), richiede di valutare il comportamento dell’AMF in situazioni in cui l’esito di un messaggio di autenticazione inviato dal terminale utente contrasta con il messaggio di “conferma” che l’AMF si aspetterebbe di ricevere dalla funzione di rete core AUSF (Authentication Server Function).

Quest’ultima è una funzione situata nella rete di origine dell’utente (e quindi potenzialmente implementata da un fornitore differente), atta a garantire che solo utenti legittimi possano accedere ai servizi della rete. Ne consegue che per condurre il test non è sufficiente attivare il processo di autenticazione lato utente, ma è necessario coordinarlo con una risposta normalmente “inattesa” da parte di un componente differente (ovvero non oggetto dello specifico test!) della rete core.

Generalizzando l’esempio precedente, le piattaforme di test SCAS devono non solo essere in grado di sollecitare, in modo programmato, la funzione oggetto dei test, ma devono anche integrare questa funzione con le altre funzioni del sistema 5G, coordinando i relativi messaggi, eventualmente alterandoli o generando messaggi malformati o temporizzati in modo anomalo, al fine di testare accuratamente la funzione in esame[3] – tutto ciò complica significativamente l’esecuzione dei test SCAS, sia che essi siano eseguiti localmente dall’operatore o dallo sviluppatore delle funzioni di rete, sia che essi siano delegati a laboratori esterni preposti a verificare o certificare la sicurezza dell’infrastruttura 5G.

A tale proposito ricordiamo infatti che i test SCAS sono stati incorporati nello schema di certificazione Network Equipment Security Assurance Scheme (NESAS), sviluppato in collaborazione tra il 3GPP e il consorzio industriale GSMA. NESAS include non solo i test SCAS per i componenti tecnici, ma valuta anche i requisiti legati ai processi, come le politiche di sicurezza, la gestione del rischio e la gestione degli incidenti. Questo schema è destinato ad essere eseguito da laboratori di testing della sicurezza accreditati da terze parti, garantendo che le apparecchiature e le funzioni software dei fornitori soddisfino i rigorosi requisiti di sicurezza stabiliti dal 3GPP[4].

Sottolineiamo, infine che, anche data la sua natura comprensiva sia di aspetti di verifica tecnica che di verifica di processo, lo schema NESAS è candidato a fungere da base per il futuro schema di certificazione europeo da parte di ENISA per la sicurezza delle funzioni di rete 5G.

Configurazioni insicure? Un esempio concreto.

Come già accennato, anche le soluzioni di sicurezza più avanzate, per quanto possano essere ritenute altamente efficaci, possono essere vulnerabili a errori di configurazione o implementazione. I test SCAS, come già spiegato in precedenza, sono progettati per validare scenari particolari e “corner cases” che, proprio in virtù della loro rarità e non convenzionalità, potrebbero essere stati trascurati o non adeguatamente coperti durante le diverse fasi di testing eseguite nel corso dello sviluppo software.

Tuttavia, come illustreremo a breve riassumendo i risultati ottenuti in alcune nostre recenti campagne di test su reti reali, abbiamo identificato una categoria di errori di configurazione particolarmente grossolani, che riteniamo facilmente individuabili (avendoli individuati noi stessi nonostante operassimo dall’ “esterno” della rete, ovvero da un punto di vista molto differente rispetto a quello ben più comodo dell’operatore!).

Più specificamente, nel caso concreto descritto nel prosieguo, ci siamo posti l’obiettivo di verificare quali algoritmi di protezione della comunicazione fossero configurati nelle reti attualmente operative, limitatamente al 4G, poiché questa era la tecnologia disponibile nella zona in cui abbiamo condotto i nostri test. Questo approccio si inserisce in un contesto più ampio in cui, come già accennato, le vulnerabilità di sicurezza nelle reti cellulari spesso derivano da configurazioni errate dei meccanismi di protezione.

Sebbene la responsabilità di garantire una corretta configurazione e di effettuare i controlli di sicurezza ricada principalmente sugli operatori di rete, riteniamo fondamentale fornire strumenti che consentano anche agli utenti comuni di acquisire una maggiore consapevolezza riguardo alla configurazione dei meccanismi di protezione adottati dagli operatori.

Con tale obiettivo in mente, in un recente lavoro scientifico[5], abbiamo documentato lo sviluppo e l’utilizzo di un nuovo tool, denominato 5GMap. Manipolando attivamente le impostazioni di sicurezza del dispositivo dell’utente durante i vari processi di configurazione della connessione e analizzando le risposte della rete, 5GMap permette di verificare gli algoritmi di cifratura e protezione dell’integrità impostati dall’operatore.

Più specificamente, per valutare l’efficacia di 5GMap, abbiamo acquisito SIM commerciali e ci siamo connessi come normali abbonati a tre dei quattro principali operatori in Italia. Nei nostri test, abbiamo esaminato il modo in cui questi operatori supportano la cifratura e l’integrità su due livelli distinti: l’Access Stratum (che comprende i protocolli PDCP/RRC, responsabili dei meccanismi di protezione dell’informazione nella comunicazione tra l’utente e la stazione radio base eNB/gNB) e il Non-Access Stratum (che riguarda il protocollo NAS, il quale gestisce la segnalazione tra il terminale utente e la funzione di accesso alla rete core dell’operatore, ossia MME per le reti 4G e 5G-NonStandAlone o AMF per le reti 5G-StandAlone).

I primi risultati ottenuti, qui riportati nella figura seguente presa direttamente dal lavoro precedentemente citato (operatori anonimizzati per ovvi motivi), sono stati particolarmente interessanti, in quanto hanno dimostrato che non solo la cifratura “nulla” può essere eventualmente negoziata dal terminale utente, ma in alcuni casi, e specificamente per due dei tre operatori esaminati, essa rappresenta l’unica opzione attualmente configurata a livello NAS. Segnaliamo che un operatore a cui abbiamo notificato tali risultati ha prontamente corretto tale configurazione.

Conclusioni

In questo articolo, piuttosto che affrontare questioni a lungo termine, abbiamo scelto di focalizzare l’attenzione su aspetti concreti e strettamente connessi alla security assurance delle reti cellulari. In particolare, abbiamo inizialmente analizzato il ruolo cruciale delle Security Assurance Specifications (SCAS) nella validazione della sicurezza delle funzioni di rete 5G.

Successivamente, abbiamo messo in evidenza come le reti attualmente operative non siano esenti da errori di configurazione significativi[6], o da scelte configurative che, ove fossero intenzionali (anche se ci permettiamo di dubitare che lo siano), tenderebbero a privilegiare in modo eccessivo la funzionalità e la connettività a scapito dei requisiti minimi di sicurezza, come ad esempio un livello base di cifratura dei dati.

Peraltro, il problema delle configurazioni insicure è ulteriormente confermato (peraltro a livello internazionale) anche da un nostro ulteriore e più recente nostro lavoro[7], dove ci siamo occupati di verificare la postura di sicurezza dei servizi VoWiFi (anche noti come WiFi calling, ovvero l’utilizzo di infrastrutture WiFi e connettività Internet operata da ISP indipendenti e/o pubblici come alternativa di accesso alle reti 4G/5G) attualmente disponibili a livello mondiale.

I risultati ottenuti confermano una certa disattenzione (se non disinteresse) verso l’utilizzo di algoritmi di protezione delle comunicazioni adeguati allo stato dell’arte. Più specificatamente, analizzando le configurazioni degli evolved Packet Data Gateway (ePDG) esposti da 340 operatori mondiali di rete mobile raggiungibili mediante URL pubbliche (su 2523 operatori a livello globale scansionati), abbiamo riscontrato che quasi il 20% dei gateway accettano cifrature deprecate (o persino compromesse, come la cifratura DES con chiave a 56 bit), e oltre il 30\% supportano gruppi Diffie-Hellman (il protocollo crittografico che permette di determinare la chiave di sicurezza usata per proteggere la sessione) di dimensioni eccessivamente ridotte e considerate ad oggi insicure.

In conclusione, trattandosi di ambiti in cui sia gli interventi che le correzioni risultano estremamente semplici e limitati al cambio di configurazioni di base, la correzione di questi errori rappresenta, a nostro parere, un “low hanging fruit” da cui partire per migliorare la postura di sicurezza delle attuali infrastrutture e prevenire un numero significativo di problemi di sicurezza.

Note e Biografia

[1] Citiamo, a titolo di esempio, i casi di Log4j nel 2022, si veda ad esempio https://www.cisa.gov/news-events/news/apache-log4j-vulnerability-guidance – ed il più recente (ed in un certo senso anche più critico visto il potenziale coinvolgimento di attori volutamente malevoli) caso di XY Utils dello scorso 29 marzo 2024 https://www.securityopenlab.it/news/3548/cybersecurity-e-open-source-cosa-ci-insegna-il-caso-xz-utils.html

[2] 3GPP. 2013. Study on security assurance methodology for 3GPP network products. Technical Report (TR) 33.805. 3rd Generation Partnership Project (3GPP). First version for Release 12

[3] Gli approcci tecnici possibili sono sostanzialmente due. Il primo approccio, che a nostra conoscenza è adottato dalla maggior parte degli attuali vendor di piattaforme di testing SCAS commerciali, consiste nell’isolare la funzione di rete da testare, integrandola in un ambiente in cui le rimanenti funzioni sono simulate. Tale approccio, seppure particolarmente costoso in fase di implementazione, data la necessità di ricreare un ambiente 5G perfettamente simulato, è particolarmente efficace in scenari di test condotti da terze parti ed a fini di certificazione.

Un secondo approccio, alternativo al precedente, è stato invece recentemente proposto e sviluppato dal nostro gruppo di ricerca a partire dal lavoro scientifico “ScasDK-a development kit for security assurance test in multi-network-function 5G”, di F. Mancini e G Bianchi, Proc. of the 18th Int, Conf. on Availability, Reliability and Security. 2023. La nostra piattaforma ScasDK (SCAS Development Kit) permette di introdurre dei proxy tra le funzioni di rete, in modo da controllare e manipolare il relativo scambio di messaggi tramite un controlle di test centralizzato.

La piattaforma fornisce anche un ambiente basato sul framework ROBOT per programmare “nuovi” test SCAS (o anche test custom). Oltre alla flessibilità aumentata data dalla possibilità di customizzare nuovi test, il vero vantaggio di questa soluzione è la possibilità di eseguire i test SCAS anche in modalità continua (o addirittura online), ad esempio integrando tali test in scenari e framework DevSecOps.

[4] Per ulteriori dettagli, il lettore può fare riferimento sia al rapporto tecnico “From NEA and NIA to NESAS and SCAS: Demystifying the 5G Security Ecosystem”, di A. Michalas, C. Patsakis, D. D. Vergados e D. J Vergados, disponibile online al link https://arxiv.org/abs/2212.09149 che alla pagina web della documentazione NESAS sulla sicurezza GSMA – https://www.gsma.com/security/nesas-documents/

[5] Andrea Paci, Matteo Chiacchia & Giuseppe Bianchi, “5GMap: User-Driven Audit of Access Security Configurations in Cellular Networks”, proc. of the 19th Wireless On-Demand Network Systems and Services Conference (WONS) (pp. 97-104). IEEE, January 2024.

[6] Si segnala che il lavoro di analisi delle configurazioni di sicurezza in reti reali è attualmente in fase di espansione. Ad oggi, abbiamo esteso le nostre verifiche a sette operatori (inclusi tre operatori virtuali), ed i risultati confermano una diffusa mancanza di attenzione, da parte della maggior parte degli operatori esaminati, verso le configurazioni di cifratura.

[7] Francesco Zampognaro, Domenico Verde & Giuseppe Bianchi, “VoWiFi Security: An Exploration of Non-3GPP Untrusted Access via Public ePDG URLs”. In proceedings of the 2024 Italian Conference on CyberSecurity (ITASEC). April 2024.