Vai al contenuto
Home » Lettera aperta a Quintarelli su SPID e Security

Lettera aperta a Quintarelli su SPID e Security

Tra poco, il 15 Marzo, entrerà in produzione lo
SPID.
Lo SPID nasce con l’obiettivo di fornire un sistema di autenticazione unico per
il cittadino, nei confronti dei siti della pubblica amministrazione. Già lo
scorso luglio ne
parlammo

quando, nelle FAQ, veniva consigliato l’uso di SSLv3 e TLS1.0 come requisito
minimo per proteggere il canale trasmissivo tra Asserting party e le Relying
party.

La discussione di questi giorni in realtà nasce su Twitter. Sollevo
l’obiezione che sarebbe stato utile fornire al cittadino, prova che i sistemi
di terze parti degli Identity Provider, ma anche dei siti che integrano lo SPID
e rimandano l’utente da un IP, sono testati dal punto di vista della security.
Quindi pubblicare, ovviamente post mitigazione, i report dei penetration test
applicativi condotti periodicamente su quei sistemi e su quelle API.

Mi viene risposto che pubblicare queste informazioni sarebbe contraddittorio e
che comunque su quei sistemi non ci sono dati dell’utente, poi modificato in
solo quelle di codice fiscale + indirizzo per raggiungibilità alternativa
(mail/telefono)
”.

E ovviamente le informazioni per autenticare l’utente, verso siti terzi
aggiungo io.

Quinta mi ha dato la disponibilità di scrivergli una email in privato per
argomentare meglio i miei dubbi e per chiarire la mia posizione. Ho preferito
la lettera aperta perché, in fondo, sono temi che oggi valgono per lo SPID ma
domani valgono per il sito istituzionale della nostra azienda. Sono temi,
quelli dello sviluppo sicuro, del test, che non hanno ancora fatto presa in chi
gestisce un progetto informatico, salvo poi trovarsi con il sistema compromesso
e lavarsene le mani.

Lettera aperta

Stefano, spero non te la prenda se ti pongo qui sul blog qualche dubbio e
perplessità. Puoi rispondermi se lo riterrai utile, in forma pubblica o
privata. Io sarò comunque felice che almeno qualcuno in parlamento sappia
cos’è una honeypot.

Se ti ricordi, via Twitter, abbiamo parlato dell’opportunità di eseguire
penetration test periodici sui sistemi che implementano lo SPID e fornire al
cittadino una prova, che questo meccanismo è messo in sicurezza e monitorato.

Mi hai rimandato alle regole
tecniche

e poi hai argomentato che non ci sono dati sensibili in mano a terzi. A parte
quelli necessari per il funzionamento del Single Sign On, già questo potrebbe
essere sufficiente.

Facciamo per un attimo finta che effettivamente gli Identity Provider non
abbiano nulla dell’utente a casa loro. Io penso che comunque, il flusso delle
chiamate che staccano il token di autenticazione debba essere testato, e
debba essere testato periodicamente.
Cosa succede se, in un rilascio successivo, un’API di un Identity Provider
permette a chiunque la invochi in maniera non lecita, di farsi dare un
token valido? E siamo sempre nello scenario, che sappiamo essere non vero,
nel quale gli IP non hanno neanche un dato dell’utente. Che succede se io
buco la macchina di uno degli Identity Provider ed ottengo informazioni che
mi permettono di generarmi OTP arbitrari? O arrivo anche solo ai dati degli
utenti?

Il penetration test applicativo, l’hardening di sistema, le linee guida di
sviluppo sicuro, sono argomenti che nel 2016 anche la PMI deve considerare
quando vuole andare online, figuriamoci una Nazione quando cerca di mettere
in piedi un meccanismo di Single Sign On con tutti i siti della PA. E’ il
single point of failure per accedere, ad esempio, a dati fiscali, a dati
anagrafici, a dati pensionistici e non lo trattiamo con la paranoia che
merita?

Il secondo punto che voglio sollevarti è questo. Prendi spunto dalla PCI.
Paragrafo 6.6, mi pare. Vengono indicate le misure minime alle quali deve
sottostare un’applicazione web per essere compliant: avere davanti un web
application firewall e subire penetration test e code review periodiche.

Per lo SPID, perché non avete dato delle linee guida di security alle quali,
chiesto l’alta affidabilità? Avete chiesto piani di disaster recovery? Avete
chiesto che i server siano protetti da firewall perimetrali e da web
application firewall? Avete chiesto vengano seguite linee guida di sviluppo
sicuro? Avete chiesto vengano fatti vulnerability assessment periodici sui
server e web application penetration test sulle API dello SPID erogate dai
sistemi coinvolti? Avete chiesto vengano fatte delle code review sul codice?
Avete chiesto che gli Identity Provider tengano monitorate le API dello SPID
da un SOC specializzato? Esiste una procedura di disaster recovery nel caso
di account compromesso?

Non possiamo limitarci a dire che le informazione date agli IP sono poche.
Quello è il substrato che permette di autenticarsi su tutta la PA. Quello è
il cuore, bucato quello, entri ovunque.

Ovviamente, se tutte queste linee guida o raccomandazioni di application
security, sono state date. Benissimo, facciamone menzione. Urliamolo ai
quattro venti e facciamo vedere che sappiamo portare a casa un sistema
informativo critico come questo dalla A alla Z. O saremo ricordati solo per i
milioni sperperati per italia.it.

Un’ultima cosa… spid.gov.it, al lancio con directory listing abilitato e
server token. Non puoi dire che tanto è un sito vetrina temporaneo, perché se
qualcuno te lo buca è comunque parte del dominio del Governo Italiano e, un
po’, la figura da cioccolattaio l’avremmo fatta tutti noi.

Con stima professionale

Paolo

Stefano se hai letto questa lettera aperta, puoi rispondere qui sotto nei
commenti. Ne potrebbe venir fuori un bel dibattito. Se preferisci la email,
puoi usare paolo@codiceinsicuro.it. Se non
ritieni la tua risposta possa dare valore aggiunto, non c’è problema. Però è
importante che chiunque legga questo post, ed ha la responsabilità di condurre
in porto un sistema web, complesso a piacere, si ponga queste domande. Perché
il prossimo sito compromesso potrebbe essere proprio il tuo, dati sensibili o
meno.

SSLv3, TLS1.0… le bestie che non debelli mai

Nelle regole
tecniche
,
paragrafo 1.2.2.3, vengono ancora indicati. Basta, davvedo, non ne possiamo
più. TLS è solo versione 1.2 ed il web server deve rifiutare i cifrari più
deboli.

Enjoy it!

Tag:

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.