Il Team per la Trasformazione Digitale si è certamente imbarcato in un’impresa che ha dell’eroico, impresa nella quale tanti prima di loro sono falliti, spesso malamente: far fare passi avanti importanti nella digitalizzazione delle nostre Pubbliche Amministrazioni. Fallimenti corredati di accuse reciproche sulle cause del fallimento e comunque sempre annunciati, anche nei pochi casi in cui invece le iniziative hanno avuto successo.
Una di queste accuse reciproche, probabilmente la più comune, riguarda il ruolo delle strutture centrali rispetto a quelle periferiche. Le strutture periferiche accusano quelle centrali di imporre norme e regole “dall’alto”, senza percezione o attenzione alle vere capacità e problematiche delle strutture periferiche. Le strutture centrali accusano quelle periferiche di disinteresse e di proteggere i propri orticelli. Probabilmente entrambe hanno spesso ragione. Il team di Piacentini, “Jumping out of the system”, sembra aver scelto la strada dell’operatività: fornire, nelle loro parole, “una serie di componenti fondamentali sui quali costruire servizi più semplici ed efficaci tra i cittadini, le imprese e la Pubblica Amministrazione attraverso prodotti digitali innovativi”. Quello che chiamano il “Sistema Operativo” del paese. Ne gioiranno sicuramente i molti, ad esempio fra i sostenitori del software libero, che hanno sempre sostenuto che con tante attività simili che le pubbliche amministrazioni svolgono, lo sviluppo di componenti (possibilmente aperti, o almeno riusabili) da rendere disponibili a tutte le PA avrebbe portato un notevole beneficio in termini di efficienza e di interoperabilità.
In tutto questo, veniamo al tema della sicurezza. Nelle parole del Team “Sicurezza e privacy sono i principi più importanti; mai, per nessuna ragione, scenderemo a compromessi”. Dopo una tale premessa, il fatto che immediatamente dopo lo stesso Team abbia messo in evidenza l’ethical hacking come attività di primaria importanza può creare qualche perplessità, soprattutto pensando alle nostre pubbliche amministrazioni.
Quale ruolo per l’ethical hacking per servizi sicuri
Vale la pena quindi di ragionare su quale sia il ruolo dell’ethical hacking nello sviluppo di servizi sicuri. Per la realizzazione di servizi sicuri, la sicurezza entra in gioco subito: la progettazione deve tenere conto delle esigenze e dei vincoli di sicurezza, in modo da non sviluppare software insicuro a cui debba poi essere “appiccicata” malamente. Ma un servizio sicuro non è solo software: l’architettura dell’ambiente di esecuzione ed i processi di gestione, sia dello sviluppo che dell’esercizio, sono altrettanto importanti. Tutti temi abbondantemente trattati negli standard di settore. Tutto questo si somma naturalmente ad una buona gestione complessiva del sistema informativo: è inutile avere un firewall se non si sa neanche quali macchine sono in esercizio e con chi devono comunicare. Alla fine, come “prova del nove”, si può anche provare un’attività di ethical hacking, per verificare che non sia sfuggito qualcosa.
Su tutto questo, diciamo che buona parte delle pubbliche amministrazioni avrebbero ancora parecchia strada da fare, strada che si è provato nel tempo a far loro percorrere, spesso con gli interventi normativi di cui sopra. È chiaro che lo sviluppo di software non rimedia a questi aspetti, se non nella prospettiva molto specifica del “codice sicuro”. Qualunque servizio può essere realizzato in modo del tutto insicuro utilizzando software perfettamente sicuro, specialmente dove ci siano poca cura, poca competenza o addirittura l’interesse a fare le cose secondo diverse priorità.
In un’azienda, quando c’è un problema di poca sensibilità dei vertici aziendali alla sicurezza dei propri sistemi informativi, una strada comune per aumentare l’attenzione è quella di commissionare un penetration test. In pratica, si incarica una società specializzata di cercare di entrare “abusivamente” (in realtà in modo autorizzato e controllato, seppure violando i meccanismi di difesa) nei sistemi dell’azienda, per metterne in evidenza le falle e la facilità o meno con cui possono essere sfruttate. Di fronte ai risultati di questa attività, generalmente allarmanti, di solito l’azienda si decide a prestare maggiore attenzione alle problematiche di sicurezza. Si tratta però di una strada difficilmente percorribile per migliaia o decine di migliaia di pubbliche amministrazioni: anche quelle che decidessero di farlo (e sarebbe una dimostrazione di attenzione non comune), avrebbero il problema di trovare abbastanza fornitori competenti e, ancora di più, fidati. Quella di “hacking etico”, infatti, è evidentemente un’attività estremamente delicata che richiede estrema correttezza da parte del fornitore e del personale coinvolto nelle attività presso i clienti, che si trova a conoscere (con possibilità di utilizzare o diffondere) informazioni chiave sulla loro (in)sicurezza.
È a questo punto che potrebbe innestarsi l’attività volontaria di ethical hacking alla quale il Team fa appello quando dice: “Vogliamo creare una policy che spieghi a tutti coloro che identificano un problema di sicurezza come segnalarlo in modo adeguato, tutelando gli utenti coinvolti grazie a una pronta risoluzione, e incentivare così tutti i cosiddetti “hacker etici” ad aiutarci in questo compito”. Un’attività di verifica sui sistemi delle PA porterebbe all’attenzione dei responsabili e del Team le vulnerabilità dei servizi esposti. A quel punto, i responsabili di quei servizi non potrebbero esimersi dal prendere provvedimenti, adottando strumenti e processi più sicuri che prima avevano trascurato, e dando necessariamente più spazio alle indicazioni del Team ed alle norme, che per buona parte già esistono ma sono per lo più disattese.
I problemi dell’ethical hacking in Italia
Sembrerebbe quindi una buona idea, ma ci sono alcuni punti di attenzione. Il primo lo conosce chiunque si sia trovato, per caso o per altro, a conoscenza di una vulnerabilità di un’organizzazione, ed abbia provato a comunicarla. Il rischio è quello di essere accusato di aver tentato un accesso abusivo ai sistemi, o di averli danneggiati, con l’aggravante eventuale dei sistemi di pubblica utilità e di accesso a dati personali o sensibili. Non credo che basti la benedizione del Team ad evitare che il nostro hacker si scontri con un dirigente zelante che decida di denunciarlo.
Il secondo rischio, più grave, è che il dirigente zelante abbia ragione. Dopotutto, l’hacker etico si distingue da quello non etico principalmente per quello che fa dopo aver trovato la vulnerabilità, non prima. E la possibilità di danneggiare i servizi è reale in ogni caso.
Non si tratta probabilmente di problemi insormontabili, e l’intenzione di creare una policy, espressa dal Team, probabilmente va proprio nella direzione di rendere la cosa più praticabile. Da tempo ci si pone il problema ad esempio di come proteggere i cosiddetti whistleblower, e anche se il tema non è esattamente lo stesso, qualcosa se potrebbe imparare da quel contesto. L’importante è affrontare il problema, soprattutto a tutela degli entusiasti che potrebbero raccogliere la sfida. In questo caso, l’ethical hacking potrebbe essere effettivamente quella spinta in più che potrebbe portare le pubbliche amministrazioni meno attente ad affrontare in modo più efficace la sicurezza dei propri servizi.
C’è sempre un’altra possibilità: che l’idea di ethical hacking sia riferita ad una installazione “di test”, i cosiddetti “challenge”. Purtroppo, questa soluzione sarebbe inefficace, perché la sicurezza di una installazione di test è ben diversa da quella di molte installazioni in esercizio. Per quel genere di verifiche, c’è l’open source.
