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.
|