Open source e sicurezza: un falso problema?
Molta gente, da studenti a professionisti free lance, scrivono software libero distribuendone i sorgenti in modo tale che chiunque li possa eventualmente modificare. Un numero sorprendente di grande aziende, tra cui giganti come IBM, contribuisce regolarmente al movimento Open Source rendendo pubblici i sorgenti di alcuni dei propri software.
Una corrente di pensiero di questo ambito sostiene che il software Open Source è più sicuro di quello commerciale, visto che chiunque può esaminarne i codici sorgente e scoprirne quindi eventuali bachi di sicurezza.
Open Source o programma commerciale?
La teoria alla base di queste affermazioni è che il software Open Source riceve, per il solo fatto di essere libero, più attenzioni e quindi è più controllabile di quello proprietario.
Questa teoria è totalmente falsa. La questione se il software Open Source sia o meno più sicuro di quello commerciale è tuttavia mal definita ,così come molte altre cose nel mondo dell’ informatica.
Cosa significa che un programma è più sicuro di un’ altro?
Supponiamo di avere due programmi, A e B e che il programma A abbia mille vulnerabilità, mentre B ne abbia una sola.
Se nessuno riesce a trovare le mille vulnerabilità del programma A anche un solo malintenzionato riesce invece a trovare l’unica vulnerabilità del programma B, quali dei due programmi è più sicuro?
Bisogna ricondurre tutta la questione a un problema di definizioni: è evidente che A abbia più vulnerabilità, ma B è più rischioso per gli utenti.
Fattori che influenzano la sicurezza degli utenti
Considerando alcuni de principali fattori che contribuiscono al livello di sicurezza di un programma tra i quali:
• la competenza in materi di sicurezza di chi sviluppa codice
• il livello di prestazioni fornito da chi sviluppa codice
• le scelte tecnologiche fatte dal team di sviluppo
• la facilità con cui è possibile problemi di sicurezza
• le azioni intraprese quando viene trovato un baco di sicurezza
• la frequenza con cui gli utenti installano aggiornamenti
• il numero e la competenza di chi cerca bachi di sicurezza
Per quanto riguarda i problemi di sicurezza?
Fatte le dovute considerazioni riguardo a questi fattori, è certamente più difficile trovare un baco di sicurezza senza poter esaminare i sorgenti di un programma, ma ciò non significa che sia impossibile. A volte, anzi , potrebbe essere molto facile, sempre che si usino gli strumenti adatti.
Inoltre, più il compito è difficile, più la sua remunerazione in termini di prestigio aumenta. Poiché i progetti di software commerciali tendono ad essere decisamente più complicati rispetto a quelli Open Source, infatti, anche nel caso la probabilità di comparsa di un baco per riga di codice fosse più bassa, il loro numero assoluto sarebbe probabilmente maggiore, visto che la loro complessità richiede ben più righe di sorgente.
Non è dunque possibile affermare in modo assoluto se i programmi Open Source siano meno o più sicuri dei programmi commerciali, in quanto le variabili in gioco sono numerose e per nulla definite, occorre dunque sia negli uni che negli altri prestare molta attenzione nella scrittura di codice avendo sempre come punto di riferimento la sicurezza degli utenti.
Articoli correlati:
Ciao,
hai pienamente ragione quando hai fatto il paragone della sicurezza del programma A e del programma B.
C’è però da dire che i programmi open source sono curati da milioni e milioni di persone in tutte il mondo: dunque se tizio trova un bug può benissimo eseguire il fix e poi distribuirlo.
Con i programmi commerciali questo non è possibile per il semplice fatto che ci lavorano dietro tot dipendenti e che il software viene aggiornato con scadenze regolari.
Michele
1) Quindi secondo lor signori le aziende del closed durante la fase di npi si occupano anche di effettuare il reverse del codice?
2) secondo lor signori in presenza di un ipotetico bug, le aziende del closed corrono ai ripari o sperano di ridurre i costi sperando che questo non venga mai pubblicato?
3) vulnerabilità e bug poi, non sono la stessa cosa, la prima è associata ad un’idea di utilizzo “fuori dagli schemi” delle varie peculiarità dell’applicazione atto ad offendere, lo sfruttamento della seconda è generalmente subordinata allo sviluppo di codice malevolo.
4) è stato totalmente trascurato il fattore tempo, che in un attacco informatico è molto più importante di qualsiasi altra cosa, i programmi A e B secondo voi, hanno le stesse probabilità di essere violati dopo 6 mesi di utilizzo (a parità di diffusione)?
5) è stato altresì trascurato il turnover del software, se avete installato sulla vs macchina un software proprietario oramai obsoleto e non più mantenuto, che non potete/volete aggiornare…esso è più o meno vulnerabile dell’ultima alternativa open disponibile?
Ora però facciamo un piccolo esempio
Usiamo come esempio di programma closed con più vulnerabilità il DES, o la macchina Enigma, ok?
Ora prendiamo come esempio di programma open l’RSA, o anche l’AES, oppure l’ELGamal…c’è bisogno di continuare? esempi così sono all’ordine del giorno, e la deduzione che evidentemente un codice modificabile da tutti è più sicuro è ovvia.
E se ancora non bastasse, mentre con i closed un malintenzionato può scoprire un bug (uno si fa per dire), nell’open un malintenzionato può scoprire il bug, ma può scoprirlo anche tutta la parte della community non deputata alla lavorazione sul software, ma che semplicemente guarda il codice…e che quindi, per così dire, ha “meno da fare”, cosa che nel closed non esiste, sbaglio?