Dapprima hanno tremato gli utenti di Windows XP. Poi è toccato a chi ancora utilizza NT. Ma il male comune, questa volta, non si tramuta in mezzo gaudio: la scelta tra rimanere vulnerabili, sia pure consapevolmente, e rischiare interruzioni del servizio è una situazione amletica. Nel migliore dei casi.

L'opinione prevalente sembra privilegiare la sicurezza ad ogni costo: si installi dunque la patch anche quando sussista il rischio di malfunzionamenti così gravi da costringere a un successivo rollback, necessario per evitare che il livello di servizio dei propri sistemi degradi oltre il limite minimo accettabile. Sacrosanto: il danno che un'intrusione da parte di malintenzionati può provocare è potenzialmente maggiore di quello che può derivare da un decadimento della qualità del servizio offerto dal sistema informativo.

Nessuno, però, vorrebbe trovarsi nei panni del resposabile I.T. che sa di rischiare grosso comunque: per colpevole imprudenza, nel caso di un attacco andato a segno in assenza della patch, o per eccessiva disinvoltura, nel caso di eccessivi downtime, necessari per il ripristino dei sistemi in difficoltà.

Chiunque produca software a livello professionale formalizza procedure di controllo e di costruzione dei casi prova, che devono essere rispettate in occasione di ogni rilascio. Ma le patch, più ancora delle modifiche evolutive, portano con sé il rischio della regressione: un cambiamento in una parte del codice sorgente può determinare, per interazione con altre porzioni dello stesso, effetti collaterali difficilmente individuabili anche a seguito di un'analisi approfondita della modifica.

Si tratta di un quadro particolarmente realistico nel caso di software complessi, che supportino le configurazioni (anche hardware) più disparate: in tali situazioni diventa oggettivamente problematico verificare che una patch non dia luogo a regressioni senza risultare, al tempo stesso, incompatibile con i rami di sviluppo evolutivo del programma. Soprattutto quando il tempo per analizzare il problema, produrre la patch ed effettuare i test sia ridotto all'osso: proprio questo sembra essere il principale problema di Microsoft, talvolta accusata di porre rimedio alle falle con tempistiche più congrue alle proprie opportunità commerciali che alle esigenze di sicurezza dei clienti.

Per lungo tempo, in quel di Redmond la linea di difesa ufficiale è consistita nel sostenere che la segretezza dei sorgenti fosse garanzia di sicurezza: in altre parole, Bill Gates e i suoi manager affermavano di potersela prendere comoda, perché, per i "cattivi", sarebbe stato quasi impossibile sfruttare i "bachi" di programmi dei quali non conoscevano l'implementazione.

Ma, come sappiamo, i fatti hanno dimostrato che le cose stanno ben diversamente: così, ecco un primo cambiamento della linea difensiva di Microsoft. Sarebbero gli scopritori dei bachi, pubblicando le proprie scoperte, a mettere irresponsabilmente i cracker in condizione di attaccare: è la tesi, a lungo propugnata, dell'anarchia informativa. La comunità della Rete ne ha subito colto l'incongruenza: se una vulnerabilità esiste ed è sfruttabile, mantenerla segreta rende gli utenti attaccabili e inconsapevoli al tempo stesso, con la conseguenza che non saranno in grado di fare alcunché per evitare il peggio. Perciò i "cattivi", che al contrario sanno come orientarsi nel vivace circuito informativo underground, risulteranno doppiamente avvantaggiati.

Di qui, la terza barricata eretta da Gates: la colpa sarebbe tutta degli utenti, che non applicano tempestivamente le patch. Ma anche tale affermazione ha incontrato pochi consensi: dal momento che per alcuni prodotti vengono pubblicate centinaia di patch in un anno, applicarle tutte con tempestività comporta il problema delle troppo frequenti interruzioni di servizio, senza contare il costo ingente rappresentato dal tempo speso. Di fatto, se la patch esce con ritardo, gli utenti corrono gravi rischi comunque.

Molti "cacciatori di bachi", in realtà, si comportano secondo il codice etico chiamato responsible disclosure: quando scoprono una falla avvertono innanzitutto il produttore del software; la pubblicazione della notizia avviene in un secondo tempo, proprio per dare modo ai laboratori di studiare a fondo il problema e produrre una patch. Ovviamente non è possibile attendere troppo a lungo, per adeguarsi al comodo e alle priorità del produttore: gli utenti sono in pericolo ed è necessario dare tempestivamente loro i mezzi per "coprirsi", rendendoli consapevoli degli attacchi che potrebbero subire e indicando le eventuali soluzioni transitorie.

In genere, il tempo accordato al produttore del programma incriminato va dai pochi giorni ad alcune settimane: alla scadenza, viene data pubblica evidenza della vulnerabilità, illustrandone con il maggiore approfondimento possibile le cause, gli effetti e gli eventuali rimedi. Spesso la notizia è diffusa attraverso la mailing list Bugtraq, frequentata da tecnici e hacker estremamente abili e preparati, per molti dei quali la ricerca di falle di sicurezza è una vera e propria attività professionale.

Nel frattempo, a Redmond sembrano finalmente essersi convinti che il rilascio di una patch deve essere rapido e va gestito "allo stesso modo in cui si effettuerebbe il rilascio di un prodotto. C'è bisogno di test più completi.", come ha recentemente affermato Craig Fiebig, responsabile della Secure Business Unit di Microsoft.

Vero, ma forse non ancora sufficiente, così come insufficiente rimane, di per sé, modificare i default di installazione di Windows in modo da attivare solo su richiesta dell'utilizzatore i servizi, come IIS, potenzialmente più attaccabili. E' necessario che il software sia concepito fin dall'inizio con l'obiettivo di realizzare la piena sicurezza: purtroppo la facilità d'uso e le caratteristiche di appeal, da sempre efficaci strumenti del marketing Microsoft, vanno nella direzione opposta. La dimostrazione è evidente, ancora una volta, nel mondo open source, dove una considerevole parte del software è prodotto al di fuori della logica commerciale consueta: meno falle critiche e, sopratutto, ricicli sulle patch praticamente inesistenti. E non si tratta della negazione del modello di business tradizionale, bensì, semplicemente, di una sua interpretazione meno esasperata.