Ma il vero punto dei livelli di servizio sono le penali, ovvero: cosa succede se invece il servizio rimane fermo per più di un giorno ogni tre anni, in violazione di quanto promesso? Così mi sono andato a cercare gli SLA del servizio, e ci ho trovato esattamente quello che mi aspettavo (alla data di oggi).

Cominciamo quindi con una serie di definizioni, la più interessante delle quali mi sembra questa:

“Downtime” means, for a domain, if there is more than a five percent user error rate. Downtime is measured based on server side error rate

Astraiamoci da Google e pensiamo a generici servizi in cloud.

Immaginiamo quindi che il servizio sia utilizzato da un’azienda per gestire la propria contabilità. Se c’è un tasso di errori di meno del cinque per cento, non è nemmeno downtime. Sarebbe interessante sapere cosa intendono per errori, ma potenzialmente la nostra azienda si potrebbe trovare con almeno una fattura su 25 registrata in modo errato (o magari persa?) senza che sia neppure downtime. Questo ci porta ad una considerazione importante: quando si parla di cloud si pensa sempre alla disponibilità, ma con la complessità di certe architetture anche l’errore e la perdita di dati sono problemi tutt’altro che trascurabili.

Ma la vera essenza dello SLA è quella riportata nel primo paragrafo e nella tabella, che è la classica clausola “per il consumatore” che si trova anche in molti contratti di connettività:

If Google does not meet the Google Apps SLA, and if Customer meets its obligations under this Google Apps SLA, Customer will be eligible to receive the Service Credits described below. This Google Apps SLA states Customer’s sole and exclusive remedy for any failure by Google to meet the Google Apps SLA.

Bene, quindi se la mia azienda resta con l’amministrazione ferma per 10 giorni… quello che ottiene sono altri quindici giorni di servizio a fine contratto. Fantastico.

Ora mi permetto una piccola analogia: immaginiamoci che un fornitore di materiale da costruzione vi venda delle travi d’acciaio che sono garantite per una certa tensione di rottura, e che vi dica che… se per caso le travi non sopportano effettivamente quella tensione, ve ne danno un’altra gratis. Le usereste per fare un ponte? No, ma non si porrebbe neanche il problema: la trave deve reggere, non importa se la trave in sé costa poco, e per garantire che regga ci si prendono una serie di margini di sicurezza notevoli. Allora, se il cloud deve servire per delle infrastrutture importanti e non solo per giocare, bisogna cominciare a ragionare negli stessi termini, compresi i margini di sicurezza dimostrabili.

Naturalmente si può dire che le infrastrutture IT sono molto più complesse di qualsiasi altra, e in parte è certamente vero, ma è anche vero che nell’IT la robustezza è un costo che si può trascurare con molta più facilità, mentre invece, proprio per la maggiore complessità dei sistemi, non dovrebbe essere così.

Giusto per fare un esempio, prima di parlare di banda larga a piacere, bisognerebbe parlare di banda garantita: se la rete sarà lo strumento con cui aziende e cittadini interagiranno fra loro e con la PA, allora non dovrebbe essere possibile un’offerta in cui la connettività va giù ad ogni temporale e viene ripristinata “nelle 48 ore lavorative” quando va bene…

Il voto da remoto non offre nessuna garanzia rispetto al controllo e alla coercizione. Addirittura, ricordo di aver letto di un liceo in US in cui i genitori controllavano chi i figli votassero (online) per il consiglio studentesco.

Il voto elettronico non offre garanzie reali rispetto a “modifiche” degli apparati o dei programmi che permettano di modificare i risultati. Non mi ripeto, chi vuole approfondire può leggere i post precedenti sull’argomento, ma il voto elettronico al seggio viene ormai abbandonato da tanti paesi proprio per motivi di sicurezza, figuriamoci quello da remoto. Su questo c’è una considerazione importante: anche se fosse possibile avere delle garanzie, sarebbero verificabili solo da tecnici informatici specializzati nel campo della sicurezza (io, ad esempio). Questo vuole dire che l’elettore/candidato, che attualmente può partecipare al processo di verifica facendosi nominare rappresentante di lista, delegherebbe tutto il suo potere di controllo a noi tecnici: quello che gli raccontiamo, lui deve credere.

In ogni caso, offrire delle garanzie seppur minime richiederebbe un processo molto più complesso e costoso di quello che leggo riguardo alle Parlamentarie…

In caso si sospettino brogli, e ricordo i sospetti di brogli alle politiche di qualche anno fa, sarebbe molto difficile fugare i dubbi, perché non ci sarebbe niente da ricontare. L’uso del voto elettronico al seggio si sta infatti orientando sempre più verso il voto verificabile mediante la stampa di una scheda cartacea, ma è praticabile solo al seggio. Il solo fatto che sia difficile fugare i sospetti di brogli secondo me indebolisce la democrazia.

Quindi, come ultima considerazione: il web e Internet sono ottimi per molte cose: fa male chi li sottovaluta, ma si illude chi pensa che ci si possa fare tutto.

È una forma di social engineering,  come tale si basa su comportamenti scorretti da parte degli utenti. Il che vole dire che si contrasta con un insieme di misure tecnologiche, di politiche ma soprattutto di sensibilizzazione specifica all’utenza. Esercitazioni di spear phishig possono mostrare come, se ben praticato, percentuali molto elevate del personale di un’organizzazione possono consegnare all’attaccante le proprie credenziali, mentre ad un attaccante spesso bastano quelle di un solo utente… Una volta avuto accesso alla rete aziendale con le credenziali di un utente, le possibilità di accesso a informazioni riservate o di praticare ulteriori attacchi per accedere alle credenziali di altri utenti sono generalmente ampissime. Trovo abbastanza curioso che ci sia sempre tanta attenzione al testing delle applicazioni web, e così poca al testing dei propri utenti. Eppure, un’attività di sensibilizzazione mirata può essere estremamente efficace, in modo misurabile.

Almeno nella sua versione Direc-recording Electronic (DRE) il voto elettronico perde sempre più appeal. Io spero (pensando a casa nostra) che esempi come questo e ancora più quello olandese, facciano riflettere meglio chi pensa che per risolvere i problemi di frodi e di efficienza del voto basti mettere un computer più o meno modificato. Le possibilità di manipolare i dati sono troppe, e chi pensa che bastino hardening e procedure più o meno rispettate per renderlo utilizzabile non ha mai veramente avuto a che fare con l’hardening e il rispetto di procedure in un ambiente ostile e propenso alla frode. E tutto questo senza considerare problemi ben più complessi che vengono introdotti, come quelli legati alle emissioni elettromagnetiche (Tempest), anche queste verificate nella pratica in Olanda. Il voto elettronico non è più economico (questo dimostrano tutti gli studi che ho letto al riguardo) e non è più sicuro, anzi: mentre le frodi con il voto tradizionale sono locali, con il voto elettronico si rischiano frodi su larga scala. L’unico vantaggio è che è più veloce nel conteggio, ma per quello basterebbe molto meno: schede stampate e conteggio elettronico. E per quanto riguarda le frodi di casa nostra, prima fra tutte la compravendita di voti fatta fotografando la scheda (o il monitor) con il telefonino, non cambia assolutamente niente. Invece di ragionare su come rendere “sicuro” il voto elettronico, come se fosse già scontato doverlo usare, proviamo a ragionare partendo dalle frodi…

Torniamo ai certificati Microsoft, che sono un problema più attuale e interessante. Io ho letto l’approfondimento tecnico, cercando una risposta ad una domanda ovvia, e cioè: se sono stati utilizzati dei certificati Microsoft, come è stato possibile ottenerli?

Bene, la parte clou della spiegazione è questa: “What we found is that certificates issued by our Terminal Services licensing certification authority, which are intended to only be used for license server verification, could also be used to sign code as Microsoft. Specifically, when an enterprise customer requests a Terminal Services activation license, the certificate issued by Microsoft in response to the request allows code signing without accessing Microsoft’s internal PKI infrastructure”

In pratica, se interpreto correttamente la spiegazione, ogni “enterprise” che abbia richiesto una “Terminal Services activation license” in questo momento si trova in mano un certificato valido per firmare software a nome di Microsoft. Sarà meglio installare l’aggiornamento

Il punto interessante però per me non è questo, e non riguarda neanche specificamente Microsoft: riguarda di nuovo l’utilizzo dei certificati come strumento di fiducia. Cosa significa firmare del codice? Significa, nel modello (molto) teorico dei certificati, garantire di aver prodotto o comunque fornito quel codice. Nota, non garantisce l’assenza di bachi, backdoor o altro, ma almeno dovrebbe garantire l’origine del codice. Quindi se io mi fido del produttore installo il codice. Allora, se il produttore non gestisce in modo corretto e sicuro il processo di firma, e di conseguenza io installo del software che mi danneggia, che responsabilità ha il produttore? In generale nulla: non è nemmeno chiaro con chi sia il contratto, visto che quando si installa del software al più si accetta una licenza, che ovviamente ha senso solo se l’origine del software è corretta. Senza approfondire oltre, provate a pensare a chi potrebbe essere responsabile nei confronti dell’utente, e vedrete che di principio non lo è nessuno. Naturalmente mi si dirà che è “il mercato” a garantire che comportamenti inadeguati puniscano il produttore… ma se così fosse, anche in tutti gli altri settori merceologici che non sono software non avremmo bisogno della garanzia, basterebbe il mercato a punire chi produce oggetti difettosi. Diciamocelo, richiamarsi sempre al mercato è nascondersi dietro a un dito, è una scusa per nascondere l’assenza di tutele.

Facciamo però un passo in più e parliamo di firma elettronica, quella in mano a cittadini e aziende. Qui il cittadino si trova con delle Certification Authority che, a differenza del produttore di soft non ha scelto (se una di queste emettesse un certificato a mio nome, io neppure lo saprei) e con delle responsabilità invece molto più pesanti di quelle di un produttore di software. Eppure lo strumento è lo stesso, mentre le competenze tecniche del cittadino sono molto minori.

Serve davvero ragionare su meccanismi alternativi a quello delle Certification Authorities, che permettano di avere le garanzie che servono e che le CA al momento non danno.

La mia riflessione però è un’altra: con tutta la nostra “scienza”, ancora non siamo stati in grado di fare sì che un meccanismo come l’aggiornamento sfugga a trucchi di così basso livello, scaricando come al solito il problema sulle spalle dell’utente? Utente che trattiamo regolarmente da incapace, ma al quale chiediamo altrettanto regolarmente di fare valutazioni e prendere decisioni che, diciamolo chiaramente, spesso neppure noi sapremmo prendere davvero con sicurezza. Certo, se mi si presenta un popup di un antivirus sconosciuto so come comportarmi, ma esaminando il traffico in rete locale è possibile ad esempio vedere il traffico del mio antivirus quando verifica gli aggiornamenti, e quindi presentare un popup che imita fedelmente quello del mio antivirus: quanti riuscirebbero veramente a non caderci?

Ma andiamo oltre: è ormai acquisito, spero, che l’aggiornamento non solo del sistema operativo, ma anche degli altri programmi è fondamentale, e quindi dovrebbe essere un’operazione la cui gestione viene facilitata all’utente. Eppure, soprattutto su Windows, ogni programma si aggiorna per i fatti suoi, ognuno con configurazioni, modi, tempi e popup diversi… e in alcuni casi, sembra, con meccanismi poco sicuri. E sappiamo anche  tutti che molti utenti, paradossalmente soprattutto i più malfidati, di fronte a tutti questi popup “per prudenza” o per fastidio li chiudono e basta. Certo, su Linux ad esempio l’aggiornamento della distribuzione copre molto più di quello che copre l’aggiornamento di Windows/Office, ma anche qui se io installo un programma che non è nella distribuzione mi devo arrangiare.

Non sarebbe allora utile un servizio del sistema operativo al quale un programma si possa registrare, e che si occupi lui di cercare dove opportuno gli aggiornamenti e di installarli in modo sicuro, naturalmente con i soli privilegi disponibili al momento dell’installazione? In questo modo, persino un programma installato dall’utente avrebbe un meccanismo di aggiornamento uniforme e gestito, ma che utilizzi i soli privilegi dell’utente stesso.

E ancora, perché le notifiche/popup di sistema sono così facilmente confondibili con quelle che può generare un qualsiasi programma? Non sarebbe importante chele notifiche di sistema e dei pochi programmi specificamente autorizzati fossero ben riconoscibili, ad esempio comparendo in un’area in cui non possono comparire messaggi anche legittimi ma di altri componenti, in modo che sia possibile per l’utente capire quali sono i veri popup di aggiornamento e dell’antivirus?

Sono solo idee buttate lì leggendo l’articolo, se vogliamo provocazioni, ma il problema è che questo genere di attenzione non c’è: è molto più semplice lasciare l’utente a decidere, magari quando è in trasferta per una decina di giorni, se sia più rischioso aggiornare il proprio computer in albergo o non aggiornarlo e lasciarlo esposto a qualche vulnerabilità o virus del momento.

(min. 6:00) “In year 2007 we had a fiscal credit bubble in the USA that rode on credit derivatives: an instrument widely used, but little understood and even less analyzed. This was, and is, a recipe for disaster. This piloted credit debt eventually imploded, leading to today’s long lasting recession. Today we have a trust bubble, riding on trust in electronic certificate’s digital signatures, cryptography and protocols. They constitute the foundations of modern information security. These functions are responsible for enrolling users and systems as trusted.” Il resto ve lo lascio immaginare, ma il video è comunque interessante. Non che dica cose che non siano state ripetute fino alla nausea, ma è interessante sentirle dire da qualcuno che non è il solito “geek”. Ma la parte che ho citato è un ottimo modo per descrivere la nostra attuale dipendenza dalle infrastrutture di certificazione, che recentemente hanno mostrato i limiti della propria affidabilità. Alcune delle “soluzioni” che ho sentito proporre recentemente le sento nominare da quindici anni, ma nel frattempo mi sono convinto della loro inefficacia. Il problema di fondo è che le terze parti “fidate” non solo sono scelte da tutti tranne che da chi si deve fidare, ma sono poco stimolate a comportarsi correttamente. Con l’attuale uso dei certificati, ad esempio per i server Web, la scelta del certificatore è fatta da chi si deve autenticare, il che non ha senso: è chi deve autenticare a dover scegliere di chi fidarsi, altrimenti si arriva necessariamente allo stato attuale. Ma lo speech mette anche in evidenza con quanta facilità dei dati che sarebbero riservati diventano accessibili “per motivi tecnici” a decine o centinaia di persone. Sono tutte cose su cui c’è molto da ragionare per trovare alternative che tengano realmente conto delle esigenze di tutti. Alla base delle CA c’è un modello fallato, che ipotizza che in qualche modo miracoloso le parti trovino un accordo basato sulla fiducia sulla terza parte fidata… l’accordo, se così si può chiamare, è fra altri soggetti e basato su criteri economici e non sulla fiducia.