Questo sito utilizza cookie per raccogliere informazioni sull'utilizzo. Cliccando su questo banner o navigando il sito, acconsenti all'uso dei cookie. Leggi la nostra cookie policy.OK

Direttore responsabile Alessandro Longo

Sicurezza Spid, “ecco perché ci possiamo fidare dell’identità digitale pubblica”

di Luca Bonuccelli, Regione Toscana

29 Lug 2016

29 luglio 2016

Tutti i motivi tecnici per cui SPID appare ragionevolmente sicuro. Nonostante le tante paure che si leggono in questi giorni da parte di vari esperti

In questi giorni in molti hanno posto l’accento sulla sicurezza del Sistema Pubblico di Identità Digitale, appare quindi evidente come l’attenzione degli addetti ai lavori e degli utilizzatori sia elevata sul tema.

Per questo motivo è utile fornire alcune informazioni di carattere tecnico al fine di dare consapevolezza del reale livello di sicurezza del sistema, livello che in generale appare elevato.

La prima “paura” è che qualcuno riesca ad “iniettare” del codice malevolo presso l’identity Provider in modo che quando gli utenti chiedono di accedere inserendo user e password il codice lo invii ad un sito dove i malintenzionati possono raccogliere questi dati.

Questo tipo di attacco non funziona se il sito è controllato e sottoposto a misure di sicurezza solide e se l’utente deve identificarsi con un meccanismo “a due fasi” (ad esempio tramite conferma via sms questa tipologia di vulnerabilità riguardo a SPID è puramente accademica: è sufficiente una azione di controllo costante sul “sito” e il pericolo è scongiurato controllo che, come meglio specificato tra qualche riga, esiste.

Un altro dubbio espresso è che il livello base di identificazione sia fatto tramite user e password per alcuni servizi (ad esempio il controllo delle multe da pagare o altri servizi).

Anche questo dubbio è facilmente fugato: in questo documento emesso da AGID è esplicitato che non è possibile accedere a servizi come quello del controllo delle multe con solo login e password.

Gli unici servizi citati come accessibili con livello 1 (login e password) sono:

-Servizio di personalizzazione (della grafica del sito pubblicamente consultabile)

-Consultazioni civiche (ossia poco più di un forum)

-Richiesta informazioni di carattere generale (che non hanno quindi impatti sulla privacy)

Altra criticità è espressa da tecnici è che il punto debole sia la postazione dell’utente il quale utilizza browser o sistemi operativi non aggiornati e quindi vulnerabili a virus o altro che permettno il furto dell’identità.

Pur comprendendo l’importanza dell’attenzione anche sulle postazioni utente questo rischio non è legato a SPID o un sistema specifico, in realtà le politiche di sicurezza del sistema sono tali da inibire l’accesso a utenti che utilizzano sistemi obsoleti, in figura si vede il messaggio che viene restituito in caso di utilizzo di un browser ormai obsoleto e non aggiornato.

 

Analizzando il protocollo ed i meccanismi di comunicazione tra i vari attori troviamo che sono  utilizzati i protocolli SAML e  SSL nella loro versione più recente.

SAML utilizza asserzioni che hanno una validità di tempo dell’ordine di qualche minuto e che una volta utilizzati non possono essere “riutilizzati” in modo malevolo, il breve tempo di validità delle informazioni impediscono i cosiddetti attacchi a “forza bruta” nel quale vengono tentate tutte le combinazioni possibili fino ad individuare quella corretta.

Per tentare tutte le combinazioni possibili occorre tempo, anche se sono utilizzati reti di calcolatori con un potenza di elaborazione notevole l’eventuale attaccante che avesse il controllo completo di una postazione di un utente ha  poche decine di secondo per forzare il sistema, quindi è obbligato a ripartire da zero.

SAML è un protocollo maturo utilizzato dai colossi della rete tra cui ad esempio Google che lo propone come meccanismo di integrazione tra i servizi di terze parti ed i propri.

Nel passato SAMl è stato oggetto di analisi accurate e nell’articolo redatto  nel 2012 (Is SAML An Effective Framework For Secure SSO? ”, Vinayendra Nataraja, 2012) vengono elencati tutti i punti di forza e di debolezza riscontrati.

Lo stesso articolo citato indica nelle conclusioni la soluzione per mitigare i rischi, principalmente connessi all’uso del browser utente come “pivot” della comunicazione tra le parti attrici.

” To mitigate risk, SAML systems need to use timed sessions, HTTPS, and SSL/TLS” cosa che in SPID è già avviene.

Altro dubbio che è stato espresso da chi non conosce il sistema è l’effetto domino in caso che uno dei tanti sistemi che costituiscono SPID si fermi o sia posto sotto attacco. In realtà proprio per l’utilizzo di SAML e di vari gestori di identità e vari gestori dei servizi SPID è una federazione composta da vari nodi.

Nel caso che uno di questi non possa più erogare il servizio gli altri nodi non vengono interessati.

Certo, ci possono essere dei disagi per una parte degli utenti che vogliono utilizzare lo specifico servizio che ipoteticamente è stato reso non operativo, ma gli altri servizi continuano a funzionare in modo indipendente.

Giova ricordare che internet nacque  come ARPANET, un progetto militare che aveva come obiettivo principale la robustezza dell’intero sistema in caso di guasti o distruzione di un nodo della rete. Questa caratteristica di robustezza non è venuta meno nella progettazione dei sistemi distribuiti e nelle federazioni come SPID

Inoltre tutti gli attori si applicano per mantenere il sistema intero sicuro ed efficiente, ad esempio tramite un monitoraggio attivo e l’analisi costante di quanto è successo.

Il monitoraggio implementato sui sistemi è orientato a verificare:

-lo stato di efficienza in termini di performance, occupazione di spazi fisici e logici, temperatura ambientale;

-la disponibilità dei sistemi (check di raggiungibilità, controlli sulle connessione attive, ecc.);

-l’esecuzione ed il corretto funzionamento delle applicazioni;

-la sistematica e corretta sincronizzazione dei sistemi con la fonte oraria di riferimento;

-l’assenza di tentativi di accesso non autorizzato;

-che i livelli di servizio siano effettivamente rispettati;

-che i processi di conservazione dei log e delle evidenze siano correttamente eseguiti.

Qualora nel corso delle operazioni di verifica e monitoraggio, il team di gestione rilevi anomalie nel funzionamento del servizio, sono attivate le analisi al fine di comprenderne cause e conseguenze nonché determinare le azioni da  intraprendere.

Gli eventi significativi che hanno impatto sul servizio sono notificati alla cosidetta Service Control Room del Gestore dell’Identità Digitale.

I cambiamenti di stato dell’evento vengono monitorati e notificati agli attori interessati.

Il gestore si avvale di gruppi specialistici per il monitoraggio della sicurezza dei Sistemi informativi che erogano il servizio. In particolare sono svolte attività di rilevazione tempestiva di eventi ed allarmi critici per la sicurezza informatica per mezzo della continua osservazione dell’infrastruttura gestita.

I suddetti eventi/allarmi sono rilevati attraverso piattaforme di Intrusion Prevention atte a difendere applicazioni e dati critici da attacchi avanzati e piattaforme di “Security Information and Event Management”per la raccolta degli eventi di Sicurezza.

Le consolle di monitoraggio sono configurate per il controllo continuo e la produzione di allarmi e report di sicurezza per le diverse tipologie di controlli effettuati. Con cadenza settimanale è prodotta la reportistica degli eventi verificatisi, al fine di valutare l’ efficacia dei controlli attuati.

Inoltre tutti gli attori sono dotati di una struttura di controllom ad esempio un identity provider dichiara:

La struttura Tutela Aziendale Fraud-Management al fine della prevenzione e gestione delle frodi sul canale internet, detiene una soluzione di Adaptive Authentication denominata “Fraud DNA”, basata su tecnologia RSA che, in maniera automatica, delinea uno scoring di rischio della sessione di autenticazione al sito.

Tale score è computato in funzione del riconoscimento del finger print della sessione (caratteristiche tecniche del dispositivo utilizzato: IP, configurazione

dei parametri di rete, S.O., browser, …) rispetto al comportamento tipico del cliente archiviato nella kwnoledge base di Poste Italiane. Inoltre è stato

integrato nell’infrastruttura Fraud DNA un servizio antimalware fraud detection volto alla rilevazione dell’eventuale presenza di codice malevolo sulla  postazione del cliente.

Il sistema cataloga in real time gli accessi ai siti di ma è impostato in modalità “invisible” lato cliente in modo da consentire comunque l’accesso del cliente anche in caso di rilevazione “High Risk”. Le attività di monitoraggio ed analisi eseguite successivamente analizzando gli scoring a più alto rischio concretizzano eventualmente il blocco degli account confermati compromessi.”

 

I Presidi di Sicurezza

Il Gestore si avvale di gruppi specialistici per il monitoraggio della sicurezza dei sistemi informativi che erogano il servizio. L’infrastruttura di sicurezza è costituita dall’insieme dei sistemi e degli apparati adibiti alla protezione dell’ambiente tecnologico ed applicativo dedicato al servizio, nonché dai meccanismi di protezione dei dati transitano o risiedono sui sistemi.

Sono svolte attività di rilevazione tempestiva di eventi ed allarmi critici per la sicurezza informatica per mezzo della continua osservazione dell’infrastruttura gestita. I suddetti eventi/allarmi sono visualizzati principalmente attraverso specifiche console di monitoraggio.

Ciascuna console è configurata per monitorare eventi diversi e produrre allarmi e report in funzione delldi come a tipologia dei controlli effettuati. Con cadenza settimanale è prodotta la reportistica degli eventi verificatisi al fine di valutare l’efficacia dei controlli attuati.

Le attività di monitoraggio delle componenti di sicurezza attraverso il controllo e l’analisi dei report viene utilizzata anche ai fini della prevenzione degli incidenti di sicurezza. Gli eventi riscontrati sono classificati in funzione della loro gravità e degli impatti che possono avere sugli asset; in relazione a tale classificazione, sono identificate le contromisure idonee a gestire l’evento. Quando dall’evento scaturisce un danno, sono svolte le attività necessarie ad accertare e valutare il danno subito nonché a definire il piano di ripristino.

In conclusione possiamo affermare che SPID appare ragionevolmente sicuro, ma (cosa più importante) è stata impostata una politica costante di attenzione sul sistema tutto; se il livello d’attenzione rimarrà tale è verosimile immaginare la messa in essere di un sempre più elevato livello di sicurezza.

 

 

  • elena

    Sarà anche vero quel che si legge qui, ma io mi doterò di SPID il giorno in cui sarò obbligata a farlo, forse pure dopo. Volontariamente MAI. Creare un single point of failure di questo tipo è un suicidio. Mi auguro che qualche hacker di buona volontà entri in tempi brevi nel sistema di un fornitore accreditato per dimostrare a tutti quanto è pericolosa sta cosa, prima che sia troppo tardi.

  • marco pandolfi

    mi sembra un’analisi “frettolosa”. anche saml ha i suoi bei problemi (a partire da http://bit.ly/2hKjzxv in poi). suggerisco la lettura dell’articolo di Paolo Perego (http://bit.ly/2hSbanN) per un opportuno approfondimento.

Articoli correlati