Security as a mindset: un servizio deve essere pensato sicuro.
Pubblico un articolo scritto da Marco Catino dedicato a un servizio conosciuto oltreoceano ma ancora pressoché sconosciuto dalle nostre parti.
Per chi lavora nel mondo della sicurezza delle informazioni non è una novità sentir dire che “la sicurezza non è una feature, ma un processo”; c’è chi si spinge un po’ oltre, e dice che “Security is a mindset”: la sicurezza è un modo di pensare. Io sono uno di questi, e credo fortemente che la sicurezza, in ambito informatico come altrove, sia un modo di pensare, di porsi, di affrontare il problema.
Ed è con questa filosofia che, anche io, predico che la sicurezza deve far parte del prodotto dall’istante in cui il prodotto viene pensato. Poiché il mondo dell’Information Technology è fondamentalmente astratto, e quindi poco adatto ai non esperti, proviamo a pensare alla sicurezza da un punto di vista più materiale: la costruzione di un grattacielo. Un’opera imponente come un grattacielo, prima che la prima pietra venga posata, viene pensato, progettato, testato e approvato, e possiamo star certi che in tutte queste fasi la sicurezza dell’edificio è sempre tenuta in considerazione. Si calcola l’impatto del vento sull’edificio, di un terremoto, di un’inondazione e, da qualche anno, anche di un attacco terroristico, e perbacco! Si vede! Raramente un grattacielo cade perché non si era calcolato qualche aspetto che riguardi la sua statica, la sua sicurezza. Questo perché la sicurezza è in prima fila, nella testa dei progettisti, fin dal momento zero.
Riportiamoci nel mondo astratto dell’ICT, in cui tutto ciò generalmente non accade. L’utente è feature-conscious, e non security-conscious, ed è per questo che quando si pensa ad una nuova applicazione, o ad un nuovo sistema operativo, si pensa a quali funzionalità l’utente possa desiderare, a cosa effettivamente lo renderà più vendibile, e raramente a cosa sia necessario fare affinché l’applicazione sia sicura. Questo è comune, direi quasi normale: il business ha l’obiettivo di fare soldi, e la sicurezza non serve a fare soldi. Poco importa se, una volta progettato un Sistema Operativo con mille mila funzionalità, ma senza solidi criteri di sicurezza, passeremo gli anni a venire installando patch cercando di mettere le pezze ai buchi, il prodotto intanto è stato venduto, e ha giustificato l’investimento fatto per realizzarlo. Certo, l’introduzione di regole e leggi nella giusta direzione, leggi che spostino il carico del fallimento della sicurezza del prodotto sul produttore, gli equilibri cambierebbero, ma questo è un altro argomento, oggetto forse di un prossimo intervento.
La mancanza di un approccio security-oriented è generalmente vero, ma non sempre. Non è vero quando il prodotto in questione fa della sicurezza, dell’implementazione sicura, il proprio motivo di essere. Un esempio che mi sta molto a cuore è quello dei servizi per la navigazione anonima e la protezione della Privacy Online. Ce ne sono tanti in giro, ma pochi, davvero pochi, sono stati pensati dal momento zero per essere sicuri. Personalmente posso parlare per un servizio, XeroBank: ogni prodotto offerto da XeroBank è stato pensato dal primo istante per essere sicuro, più ancora che affidabile o performante, e questo perché un fallimento nella sicurezza del servizio vorrebbe dire la compromissione della privacy del cliente, ciò che sta più a cuore all’azienda, ciò che rappresenta il business dell’azienda. Per questo tutti i servizi, compresi quelli per i privati, sono pensati per essere fail-secure.
Un prodotto o servizio si definisce fail-secure quando, in caso di guasti o anomalie, si comporterà in modo da mantenere sicuri i dati trattati, anche a costo di smettere di funzionare o eliminare definitivamente i dati in questione. Questo è un comportamento che all’utente generalmente non piace, un comportamento di cui il cliente non può apprezzare l’utilità, ed è per questo che il 99,999% dei servizi sono fail-safe, pensati cioè per continuare a funzionare, in un modo o nell’altro, anche in caso di malfunzionamenti. Questo accade spesso a costo della sicurezza, e l’esempio più classico è il downgrade delle connessioni web sicure (https) a connessioni non cifrate (http) nel momento in cui il protocollo SSL presenta qualche problema; l’approccio sicuro in questa eventualità? Interrompere la fruizione del servizio, semplice. Bene, ora che l’avete letto, siate pronti a non vedere mai un comportamento del genere.
Vorrei concludere questo mio primo intervento ricordando che:
· La sicurezza è una forma mentis, e non una semplice caratteristica;
· Un progetto, per essere sicuro, deve essere pensato sicuro dal momento zero;
· Per un servizio che offre navigazione anonima e privacy online è indispensabile un approccio security-oriented;
· Definiamo una soluzione fail-safe se fa di tutto per funzionare, a qualsiasi costo, e fail-secure se fa di tutto per proteggere i dati che gestisce, a costo di diventare inservibile.
Il Copyright di questo articolo è detenuto da Marco Catino, autore dello stesso.
E’ consentito creare collegamenti ipertestuali verso questa pagina. E’ consentita la riproduzione parziale o totale di questo articolo, a condizione che (I) nella stessa pagina in cui è riprodotto il contenuto di questo articolo sia presente un link naturale a questa pagina e un link naturale a www.xerobank.it e (II) il significato e il messaggio di questo articolo non siano in alcun modo cambiati.
Articoli correlati:
[...] infatti non vi parlo dei suoi prodotti, quanto di un nuovo forum che tratta principalmente di privacy online ma che contiene anche la sezione “sicurezza informatica” dove appunto, potrai postare [...]