Pagina pubblicata tra il 1995 e il 2013
Le informazioni potrebbero non essere più valide
Documenti e testi normativi non sono aggiornati

 

Pubblica amministrazione e open source

Sicurezza: la soluzione è nei sorgenti aperti
di Andrea Gelpi - 06.02.03

Dopo l'ultimo blocco di una parte di Internet a causa di un virus (tecnicamente un worm) che ha colpito solamente i server che montano software Microsoft, si è scatenata la caccia al colpevole. Si sono creati due "partiti", il primo afferma che è tutta colpa di Microsoft che produce software con troppi problemi, l'altro afferma che è colpa degli amministratori di sistema che non hanno applicato i correttivi, anche se disponibili già da un po'.
Per dovere di cronaca va ricordato che questa non è la prima volta che un virus colpisce i sistemi progettati a Redmond, basti pensare a CodeRed e Nimda, per non parlare di tutti quei virus che si propagano solo tramite vulnerabilità dei client di posta Microsoft (Outlook).
Microsoft si difende affermando che i suoi sistemi sono i più diffusi, per cui è ovvio che siano i più colpiti. Sarà anche vero, ma qualche dubbio rimane.

Io credo il problema stia altrove, vediamo il perché.

Microsoft da sempre ha cercato di rendere i propri sistemi semplici da utilizzare (le operazioni si fanno con qualche clic) e fin qui la cosa è lodevole, ma diventa terribilmente pericolosa nel momento in cui lo stesso ragionamento viene applicato alla configurazione e gestione del sistema anziché il semplice uso. A forza di limitarsi a fare clic qua e là il sistemista perde il reale controllo del sistema e non è più a conoscenza dei meccanismi che lo regolano al suo interno. Secondo me, Microsoft si è troppo concentrata sul rendere "user friendly" i propri sistemi, mettendo in secondo piano altri aspetti, fra cui la sicurezza.
La cosa ha funzionato senza troppi problemi finché i sistemi erano isolati (come i PC casalinghi) o comunque poco connessi fra loro (LAN), ma è entrato in crisi con l'avvento di Internet in quanto gli amministratori dei sistemi si sono ritrovati fra le mani tutta una serie di problematiche di cui non sospettavano nemmeno l'esistenza, proprio per la mancanza di conoscenza del funzionamento interno dei sistemi da loro gestiti. Il risultato è sotto gli occhi di tutti.

Un bravo sistemista sa per esperienza che sui sistemi in "produzione" i correttivi non vanno applicati subito appena resi disponibili, ma è consigliabile o provarli di persona prima su ambienti di sviluppo o verificarne la bontà negli appositi forum di discussione, sparsi per tutto Internet. Insomma è buona norma aspettare un po'.
Questo ragionamento nasce dal fatto che sia le nuove versioni che i correttivi potrebbero avere dei problemi e quindi è meglio andare con i piedi di piombo.

Inoltre un'altra buona regola dice che se tutto funziona non è proprio il caso di fare modifiche.

Questi due ragionamenti funzionano perfettamente in tutti i casi, meno uno, quello della sicurezza. Quando un correttivo non serve per eliminare un errore del programma, ma per chiudere una falla di sicurezza, non si può aspettare. L'esperienza di questi ultimi anni insegna che dal momento dell'uscita di un correttivo e spesso quindi, anche della notizia dell'esistenza di una falla di sicurezza in un qualche sistema, si hanno da uno a due mesi di tempo prima che qualcuno metta in circolazione un qualche cosa in grado di sfruttare la vulnerabilità. Ecco allora che mentre resta valido il ragionamento del "testare il correttivo prima di usarlo", non è più valido il secondo ragionamento "se tutto funziona non toccare".

Gli amministratori dei sistemi si trovano quindi nella necessità di dover discriminare fra un aggiornamento che va installato al più presto e uno che invece può aspettare. Vista la frequenza con cui escono i correttivi, se in un centro i sistemi sono molti o c'è chi si dedica solo alla loro installazione, o come capita nella maggior parte dei casi i correttivi non vengono applicati, perché l'amministratore di sistema ha altro da fare. Si potrebbe qui aprire il discorso sulla cultura della sicurezza, ma il discorso ci porterebbe troppo lontano.

Esiste poi una situazione paradossale. Quando si inizia l'installazione di un correttivo o di un service pack compare la finestra con la licenza che contiene il famoso disclaimer, cioè una frase che più o meno suona così: "Questo software è rilasciato così come è e il produttore non è responsabile per gli eventuali danni derivanti dall'uso dello stesso". Quindi l'amministratore di sistema deve accollarsi il rischio di eventuali danni causati dall'installazione del correttivo. Ma se l'amministratore è stato abituato solo a fare dei clic qua e là, come farà a capire, a decidere se installare o meno? Tutto quello che può fare è un atto di fede o meglio sperare, incrociando le dita, che tutto fili liscio. Purtroppo non sono rari i casi in cui i correttivi una volta installati creano più problemi di quelli che dovevano risolvere, e non sempre esiste una procedura per tornare indietro, per lo meno prevista dal produttore del software.

Qui sta, a mio avviso il vero problema. Noi utenti ci siamo abituati e consideriamo normale che un software possa anche non funzionare (basta pensare ai crash dei sistemi) e i produttori dormono sonni tranquilli, tanto hanno il disclaimer nella licenza.

Qualcuno a questo punto penserà che sarebbe auspicabile una legge che modifichi la situazione, ma non credo sia una strada valida. Come farà l'utente finale a dimostrare che il danno subito è colpa del produttore se il software in questione è proprietario e chiuso, e l'utente non ha la possibilità di esaminare i sorgenti?
Siamo quindi in un vicolo cieco? Io credo di no. La soluzione sta nell'adottare sistemi con sorgenti aperti, e magari già che scelgo di cambiare ne cercherò uno con meno problemi.