Dichiarazione comune sulla sicurezza di GNU/Linux
4 Aprile 2004
Estratto
I produttori GNU/Linux Debian, Mandrake, Red Hat e SUSE si sono uniti per dare una risposta comune all'articolo di Forrester intitolato "Is Linux more Secure than Windows?" (Linux è più sicuro di Windows?). Nonostante l'articolo dichiari di dare un giudizio qualitativo delle reazioni del produttore alle vulnerabilità più serie, le tratta tutte allo stesso modo, senza tener conto del loro rischio per l'utente. Di conseguenza le conclusioni ricavate da Forrester hanno un valore estremamente limitato nel mondo reale per i nostri utenti che fondano le loro opinioni sul problema pratico di quanto velocemente sono corrette le vulnerabilità più serie.
Comunicato completo
I team responsabili della sicurezza delle distribuzioni GNU/Linux Debian, Mandrakesoft, Red Hat e SUSE hanno collaborato con Forrester nella raccolta e nella valutazione dei dati sulle vulnerabilità nei loro prodotti. I dati raccolti sono stati usati da Forrester per scrivere un articolo intitolato "Is Linux more Secure than Windows?" (Linux è più sicuro di Windows?). Mentre i dati sulle vulnerabilità di GNU/Linux alla base dell'articolo sono considerati sufficientemente accurati e precisi da Debian, Mandrakesoft, Red Hat e SUSE, d'ora in poi indicati con "noi", siamo preoccupati delle conclusioni fatte dall'articolo.
Noi crediamo che sia nell'interesse della nostra utenza e della comunità del Software Libero rispondere all'articolo di Forrester usando la forma di un comunicato comune:
Siamo stati contattati da Forrester nel febbraio 2004 per aiutarli ad affinare i loro dati. Forrester ha raccolto dati sulle vulnerabilità che hanno afflitto GNU/Linux nel periodo di un anno (da giugno 2002 a maggio 2003) controllando il numero di giorni occorsi per fornire le correzioni agli utenti. Particolare attenzione è stata posta non solo nell'accertamento che la vulnerabilità fosse effettivamente corretta ma anche nel chiarire le particolari attenzioni tecniche e organizzative prese durante il processo di risposta nel campo della sicurezza professionale nel Software Libero. Quest'aspetto è enormemente apprezzato dagli utenti perché aggiunge un alto valore ai nostri prodotti, ma riteniamo che la maggior parte di questo valore sia stato ignorato con il metodo d'analisi delle vulnerabilità portando a conclusioni errate.
I nostri team di sicurezza e le organizzazioni specializzate in sicurezza dalla reputazione più che rispettabile (come CERT/DHS, BSI, NIST, NISCC) si scambiano informazioni sulle vulnerabilità e cooperano per stabilire le contromisure e le procedure di correzione. Ciascuna vulnerabilità è approfondita e valutata singolarmente; la severità della vulnerabilità è determinata da ciascun team di sicurezza in funzione del rischio e dell'impatto ma anche su altre proprietà, principalmente tecniche, del problema e del software con il problema. Questa severità è poi usata per determinare la priorità a cui la correzione della vulnerabilità viene elaborata rispetto alle altre vulnerabilità in lista d'attesa. I nostri utenti sanno che in caso di problemi critici possiamo rispondere in poche ore. L'attribuzione di priorità significa che le questioni meno importanti sono spesso rinviate per permettere prima la correzione dei problemi più importanti.
Contrariamente a ciò che afferma Forrester non distingue quando si misura il tempo trascorso dalla conoscenza pubblica del problema di sicurezza a quando il produttore rende disponibile una correzione. L'articolo fornisce per ciascun produttore una semplice media, "All/Distribution days of risk" (Giorni a rischio Totali/per Distribuzione), che non da un'immagine completa dell'esperienza reale sperimentata dagli utenti. La media erroneamente tratta tutte le vulnerabilità allo stesso modo senza tener conto del rischio a cui espongono il sistema, infatti, non tutte le vulnerabilità hanno lo stesso impatto su tutti gli utenti. È stato fatto un tentativo di classificare le vulnerabilità in base alla severità usando dei dati da terze parti, in ogni caso la classificazione "severità-alta" non è sufficiente: il semplice annuncio di una vulnerabilità da parte di una particolare organizzazione non necessariamente rende la vulnerabilità grave, allo stesso modo la possibilità di un exploit da remoto è spesso irrilevante per la severità della vulnerabilità.
Riteniamo che l'articolo non tratti i produttori di Software Libero e l'unico produttore di software proprietario nello stesso modo. Il Software Libero è conosciuto per la sua varietà e per la libertà di scelta fra gli standard che definisce. Solitamente agli utenti desktop che a quelli server sono offerte più implementazioni di questi standard, lasciando agli utenti la libertà di scegliere il software in base ai propri criteri piuttosto che quelli del produttore del software. Il codice sorgente aperto, trasparente e tracciabile è un valore aggiunto che si somma al numero più elevato di pacchetti software disponibili. Infine il fatto che uno dei produttori di software abbia risolto il 100% dei suoi problemi nel periodo coperto dall'articolo dovrebbe essere un incentivo per un'analisi più accurata delle conclusioni cha l'articolo presenta.
Firmato,
Noah Meyerhans, Debian
Vincent Danen, Mandrakesoft
Mark J Cox, Red Hat
Roman Drahtmüller, SUSE
Informazioni aggiuntive:
Javier Fernández-Sanguino Peña ha fatto uno studio nel 2001 in cui si rileva che il team di sicurezza Debian ha impiegato in media 35 giorni per correggere le vulnerabilità annunciate sulla lista Bugtraq. Comunque più del 50% delle vulnerabilità sono state corrette entro 10 giorni e oltre il 15% nello stesso giorno in cui è stato pubblicato l'avviso! In questa analisi tutte le vulnerabilità sono state trattate allo stesso modo.
Javier ha rifatto lo studio basandosi sulle vulnerabilità scoperte fra il 1 giugno 2002 e il 31 maggio 2003 e ha scoperto che la mediana del ritardo fra la divulgazione e il rilascio di un avviso che contiene una correzione è stato di 15,5 giorni (la media è di 31,10 giorni). Di nuovo in questa analisi gli avvisi non sono stati classificati in base alla priorità.