Sicurezza nella PA: dal codice al dialogo

Il Team per la Trasformazione Digitale guidato da Diego Piacentini si era posto un obiettivo sopra a tutti gli altri:

Sicurezza e privacy sono i principi più importanti; mai, per nessuna ragione, scenderemo a compromessi

Un punto che è diventato il primo di una dozzina di obiettivi da perseguire, di principi da rispettare, un vero e proprio manifesto d’azione su cui costruire il biennio entro il quale si conta di dare una sferzata alla digitalizzazione della PA nel nostro paese. A seguito della pubblicazione del manifesto, Webnews portò avanti una proposta mirata, legata alla possibilità di introdurre un nuovo modo di considerare la sicurezza e il rapporto con il mondo esterno alla PA. Ecco perché suonano dolci le note di Giovanni Bajo e Gianluca Varisco, nomi che accompagneranno le questioni di sicurezza durante lo sviluppo dei servizi che emergeranno dal lavoro del team:

La sicurezza non riguarda dicotomie, non si misura in bianco e nero, ma si rivaluta sempre in ogni istante: un software che si considera sicuro oggi, potrebbe rivelarsi improvvisamente inadeguato, nel caso in cui qualcuno vi trovasse una vulnerabilità. Per questo esistono solo livelli di sicurezza, e quello di un software dipende da molteplici fattori come la tipologia dell’attaccante o il budget a sua disposizione.

Con una sola frase Bajo e Varisco smarcano i propri progetti dalla faciloneria del giudizio affrettato sulla sicurezza della PA. E questo perché non esiste software sicuro e software insicuro: esistono vari gradi di sicurezza, varie accortezze da adottare, varie policy da implementare. Un software, o un servizio, potrà dirsi ragionevolmente sicuro qualora le misure adottate comportino, a fronte di un eventuale attacco, una barriera di sicurezza sufficiente. Prima ancora di mettere mano al codice, quindi, viene installata una nuova consapevolezza che tutti dovranno far propria:

Identificare e risolvere problemi di sicurezza in qualunque software è dunque una pratica ordinaria e comune.

Se si vuole lavorare per la sicurezza, quindi, occorre adottare, prima ancora di software sicuri, un certo tipo di approccio: la sicurezza non va valutata in fase di acquisto o di adozione di un software, quanto nella pratica quotidiana di utilizzo e manutenzione dello stesso, affinché il lavoro continuo di controllo e ottimizzazione consenta di metabolizzare quei ruoli e quei protocolli necessari a garantire la reale tutela dei dati e delle procedure della PA. «È molto meglio, e sicuramente conveniente, premiare un ethical hacker per il suo lavoro, migliorando la sicurezza del proprio software, piuttosto che infilare la testa sotto la sabbia e aspettare che “black hat hacker” (gli hacker “cattivi”) scoprano gli stessi problemi e li usino indebitamente per arrecare danno». Ecco perché su Webnews poniamo sempre molta attenzione all’uso di parole come “hacker” o “cracker”: il distinguo è fondamentale affinché possano svilupparsi una comunicazione e una consapevolezza aderenti alla realtà, sfociando quindi in pratiche come quella che il Team per la Trasformazione Digitale sta cercando di porre in essere.

Sicurezza, il primo punto dei nostri principi. Con @giovannibajo iniziamo a costruire una community @teamdigitaleIThttps://t.co/8stXeWjaEM

— Gianluca Varisco (@gvarisco) December 21, 2016

Responsible disclosure

Per “responsible disclosure” si intende l’apertura di un canale privilegiato per il dialogo con gli hacker che vorranno mettere a disposizione della PA le proprie competenze e le proprie scoperte. Qualora qualcuno scopra un bug, insomma, deve avere la possibilità di segnalarlo agli organi competenti affinché si possa agire a risoluzione dello stesso senza arrecare danno alcuno né al sistema, né alle persone coinvolte. La testimonianza del bug, insomma, deve consentire alla PA di salvaguardare i cittadini e di risolvere il problema, il tutto senza che cracker terzi possano venire a conoscenza del bug per approfittarne con danno per la collettività.

Il credo del team nella responsible disclosure si scontra con un vuoto normativo e regolamentare che necessita evidentemente di essere colmato: con quali regole si può mettere in piedi un sistema di questo tipo? Chi deve farsene carico? Quali sono i protocolli di sicurezza da mettere in piedi? Come si può garantire l’assoluta segretezza delle comunicazioni e l’immediata valutazione delle segnalazioni in entrata?

In ballo v’è inoltre un aspetto ulteriore: come assicurarsi la collaborazione degli hacker? Come restituire qualcosa a coloro i quali segnalano i bug scoperti, rendendo tale processo sufficientemente interessante (quantomeno più interessante rispetto alla segnalazione ad eventuali malintenzionati o più semplicemente alla stampa per portarsi a casa lo scoop di turno)?

Riteniamo anche che sia giusto ricompensare chi, identificando un problema, lo comunica in modo tempestivo e privato, rimandandone la diffusione solo a quando il problema è stato risolto. Un programma di responsible disclosure ha anche l’obiettivo di agevolare la rapida risoluzione dei problemi di sicurezza e minimizzare i rischi per la cittadinanza. La tempestività nel risolvere le falle risulta cruciale per ridurre la finestra temporale in cui i nostri software sono esposti agli attaccanti. È per questo motivo che abbiamo intrapreso un percorso con il CERT Nazionale e il CERT-PA per definire e pubblicare una policy di responsible disclosure nazionale; stiamo contemporaneamente indagando lo scenario tecnico e normativo (inclusa la protezione legale di chi fa la disclosure) per verificare i presupposti per il lancio del programma. Valuteremo anche l’opportunità di sperimentare una forma di bug bounty.

Bug Bounty

Un programma di bug bounty (qui anzitempo suggerito da Webnews), così come anche la sola valutazione preventiva di tale opportunità, è un passo che ha enorme significato e non soltanto per la sicurezza dei servizi della PA. Un programma di questo tipo significherebbe l’interiorizzazione di principi fino ad oggi estranei alla PA; significherebbe l’apertura di un dialogo che crea coinvolgimento (invece che distanza) rispetto ai progetti della PA; significherebbe la creazione di protocolli che rendono l’attenzione alla sicurezza un discorso quotidiano e continuo, non certo sporadico e sottovalutato.

Un programma di bug bounty sarebbe la capitalizzazione della consapevolezza che il team di Piacentini sta cercando di apportare tra le righe del “Sistema Operativo del Paese”:

L’ascolto, la trasparenza e la condivisione sono i valori cruciali che guidano le azioni di questo team; infatti, per guidare l’Italia nel futuro, è necessario condividere con tutti visione, missione, obiettivi, codice sorgente (quando appropriato), design, idee, successi e anche insuccessi.

Vogliamo creare una policy che spieghi a tutti coloro che identificano un problema di sicurezza come segnalarlo in modo adeguato https://t.co/OLn8wM7zIZ

— Diego Piacentini (@diegopia) December 21, 2016

Perché i progetti messi in ballo, come ampiamente spiegato da Piacentini, debbono andare oltre Piacentini stesso: occorre mettere in moto un macchina in grado di alimentare nuove soluzioni anche oltre la scadenza predeterminata del team. Principi da infondere, prima ancora che idee da realizzare: il lavoro inizia quindi da post esplicativi, approfondimenti di quel manifesto programmatico da cui il “Sistema Operativo del Paese” dovrà vedere la luce.