Ospitiamo la traduzione italiana di un articolo di Bruce Schneier comparso sul numero di novembre 2005 della sua newsletter Crypto-Gram. La traduzione è opera di Communication Valley che ci ha concesso di ripubblicarla. Il testo in italiano dell’intera newsletter (pdf, 94 K) è disponibile nel sito di Communication Valley.

A una conferenza sulla sicurezza tenutasi il mese scorso, Howard Schmidt, ex-consigliere sulla sicurezza cibernetica alla Casa Bianca, ha coraggiosamente sostenuto che gli sviluppatori di software dovrebbero essere resi personalmente responsabili della sicurezza del codice che scrivono.
Schmidt è sulla strada giusta, ma ha commesso un pericoloso errore. Sono i produttori di software che dovrebbero essere resi responsabili, non i singoli programmatori. Se si lavora a questa idea nel modo giusto, si otterrà software più sicuro per tutti; se l’approccio è sbagliato, il risultato sarà semplicemente una confusa sequela di cause giudiziarie.
Per comprendere la differenza, è necessario capire gli incentivi economici basilari delle aziende, e come le responsabilità agiscono sulle imprese. In una società capitalistica, le compagnie sono imprese che mirano al profitto, e le loro decisioni vengono prese in base a una redditività a breve e a lungo termine. Cercano di bilanciare i costi di un software più sicuro (più sviluppatori, meno funzionalità, tempistiche più lunghe per la commercializzazione) contro i costi di software non sicuro: spese per la realizzazione delle patch, un’occasionale pubblicità negativa, perdita potenziale delle vendite.
Il risultato lo vediamo tutti: software pessimo. Le aziende trovano che sia più economico resistere all’occasionale tempesta di pubblicità negativa, spendere soldi in campagne di pubbliche relazioni che vantano ottima sicurezza, e risolvere i problemi pubblici dopo il fatto, invece di progettare e considerare la sicurezza fin dall’inizio.
Il problema di quest’analisi è che la maggior parte dei costi del software insicuro ricadono sugli utenti. In economia questo fatto viene chiamato esternalità: l’effetto di una decisione non viene sostenuto da chi ha preso quella decisione.
Normalmente ci si aspetterebbe che gli utenti rispondessero favorendo i prodotti sicuri a scapito di quelli non sicuri: dopotutto stanno prendendo le loro decisioni di acquisto basandosi sullo stesso modello capitalistico. Ma ciò non è generalmente possibile. In alcuni casi, certi monopoli in ambito software limitano le scelte a disposizione nell’acquisto di un prodotto; in altri casi, l’effetto di “chiusura” creato da formati di file proprietari o da un’infrastruttura già esistente o da requisiti di compatibilità, rende più difficile il cambiamento; e in altri casi ancora, nessuna delle aziende concorrenti ha fatto della sicurezza un elemento di distinzione. In ogni caso, per l’acquirente medio è difficile distinguere un prodotto veramente sicuro da un prodotto non sicuro ma con una campagna di marketing tutta mirata a decantarne la sicurezza.
Il risultato finale è la grande diffusione di software non sicuro. Ma dato che sono gli utenti a pagarne il prezzo, e non i produttori di software, non vi sono miglioramenti. Rendendo responsabili i produttori di software si rimedia a questa esternalità.
Si osservi il meccanismo in funzione. Se gli utenti finali possono denunciare i produttori di software per difetti presenti nei prodotti, allora il costo di quei difetti aumenterà per i produttori di software, che finiscono col pagare il reale costo economico del pessimo software, e non solo una parte di esso. Per cui, quando si tratta di bilanciare da una parte il costo per rendere sicuro il proprio software e dall’altra il costo di lasciarlo insicuro, i costi di quest’ultima saranno decisamente maggiori. Ciò fornirà un incentivo per rendere il software più sicuro.
Sicuramente, rendere il software più sicuro avrà i suoi costi, e i produttori dovranno passare quei costi agli utenti finali aumentando i prezzi. Ma gli utenti stanno già pagando i costi addizionali del software non sicuro: i costi per prodotti di sicurezza di terze parti, i costi delle consulenze e delle società che offrono servizi di sicurezza, i costi diretti e indiretti delle perdite. Rendere i produttori di software responsabili fa muovere maggiormente quei costi, e come prodotto secondario causa l’aumento in qualità del software.
Ecco perché l’idea di Schmidt non funzionerà. Egli vuole che siano responsabili i singoli sviluppatori di un software, e non le aziende.
Ciò fornirà senza dubbio un capro espiatorio che gli utenti arrabbiati potranno denunciare, ma non ridurrà l’esternalità e non risulterà in un software più sicuro.
La sicurezza informatica non è un problema tecnologico, ma economico. I socialisti possono immaginare che le aziende miglioreranno la sicurezza dei programmi come spontaneo atto di buona volontà, ma i capitalisti sanno che ciò deve rientrare nel miglior interesse delle aziende. Avremo meno vulnerabilità quando chi ha la capacità di ridurre tali vulnerabilità avrà l’incentivo economico di farlo. Ed è per questo che soluzioni quali responsabilità e normative funzionano.

I commenti di Schmidt: <http://news.zdnet.co.uk/software/developer/0,39020387,39228663,00.htm>
Il thread su SlashDot riguardante le problematiche sollevate da Schmidt: <http://developers.slashdot.org/article.pl?sid=05/10/12/1335215&tid=172& tid=8> oppure <http://tinyurl.com/dvpd7>
Dan Farber ha fornito un buon commento al mio articolo. <http://blogs.zdnet.com/BTL/?p=2046>
Questo articolo è originariamente apparso su Wired.com: <http://www.wired.com/news/privacy/0,1848,69247,00.html>
C’è stata un po’ di confusione a riguardo nei commenti (sia su Wired che nel mio blog), e molti hanno pensato che ciò significhi che ci si aspetterà la perfezione da parte dei produttori di software e che saranno ritenuti responsabili al 100% se ciò non accadrà. Ovviamente una cosa del genere è ridicola e non è certo questo il modo in cui funzionano le responsabilità. Ma egualmente ridicolo è ritenere che i produttori di software dovrebbero essere del tutto esenti da responsabilità sui difetti. Una quantità ragionevole di responsabilità sta più o meno nel mezzo, ed è questo ciò che devono calcolare i tribunali.
Howard Schmidt scrive: “È spiacevole che i miei commenti siano stati riportati in modo inesatto; almeno Dan Farber nel suo blog ha cercato di correggere le inesattezze riportate. Io non sono a favore di RESPONSABILITÀ PERSONALI per gli sviluppatori NÉ supporto la responsabilità contro i produttori: essi non sono altro che persone (impiegati compresi) e qualsiasi cosa contro di loro va a scapito proprio di quelle persone a cui è necessario fornire strumenti, addestramento e supporto migliori”.
Howard ha scritto questo intervento sull’argomento per spiegare ciò che pensa davvero. Ed è contro le responsabilità legate al software.
<http://news.com.com/Give+developers+secure-coding+ammo/2010-1002_3-5929 364.html> oppure <http://tinyurl.com/dmlgh>
Ma la prima frase del suo ultimo paragrafo ben riassume quanto c’è di sbagliato nella sua argomentazione: “Alla fine, quel che richiede la sicurezza è la stessa attenzione che occorre per qualsiasi obiettivo commerciale”. Se la sicurezza deve essere un obiettivo commerciale, allora deve avere anche un senso commerciale. Al momento, ha più senso (commercialmente parlando) non produrre software sicuro rispetto a produrre software sicuro. Una qualsiasi soluzione al problema deve affrontare questo fondamentale errore di mercato, invece di volere semplicemente che fosse vero.

Articoli collegati

IsacaRoma Newsletter: intervista a Bruce Schneier;
IsacaRoma Newsletter: intervista a Giovanni Bobbio di Communication Valley;
IsacaRoma Newsletter: intervista a Francesco Fullone sulla programmazione sicura.