Full disclosure. Risorsa o pericolo per la sicurezza?

ICT-Security n.ro 3 del 01-03-02

di Andrea Monti

Sembra essersi spenta – o quantomeno attenuata – l’eco generata dalla polemica “scoppiata” l’anno scorso sull’opportunità di praticare “full disclosure”. Cioè la pubblicazione dettagliata di bug e vulnerabilità che affliggono endemicamente un po’ tutte le piattaforme e gli applicativi del mondo ICT a cura di ricercatori indipendenti. Che divulgano sia l’analisi teorica del problema, sia l’exploit che consente di sfruttare praticamene il “buco” di sicurezza. Ma la questione è tutt’altro che sopita specie perché non è stata affrontata – a quanto mi risulta – dal punto di vista dell’organizzazione aziendale e dei riflessi legali.

Questo modus operandi ha infastidito molti “giganti” del settore che – a tacer d’altro – non devono aver gradito la sistematica esposizione al “pubblico ludibrio” quando i mezzi di informazione rilanciano la notizia dell’ennesima vulnerabilità che affligge questo o quel prodotto. Come non devono avere gradito le probabili proteste dei security manager (specie di ambito corporate) che cominciano a domandarsi per quale motivo dovrebbero continuare a investire porzioni consistenti dei propri budget in prodotti che sembrano creare più problemi di quanti ne risolvono. Soprattutto a fronte della “ponziopilatesca” attitudine dei fornitori di invocare le clausole di limitazione di garanzia e responsabilità inserite nelle licenze d’uso.

Al di là delle ragioni degli opposti schieramenti (no alla full disclosure perché agevola azioni illegali – si alla full disclosure perché consente una protezione più rapida ed efficiente) è importante capire che il dibattito su questo tema fa riferimento a due modelli “filosofici” della sicurezza che si autoescludono reciprocamente. Uno, quello che “blocca” la circolazione delle informazioni, concentra nelle mani del produttore di software ogni possibilità di controllo della sicurezza, escludendo così aprioristicamente qualsiasi intervento dell’utente. Il cui ruolo, nella gestione della sicurezza, si limita a gestire il “fattore umano”, il controllo delle politiche di accounting, l’architettura della rete ecc.

L’altro, quello basato sulla libera circolazione delle informazioni, offre la possibilità di una sicurezza gestita dall’interno, più tempestiva e, soprattutto, nel pieno controllo dell’azienda.

E’ chiaro che ciascuna scelta ha delle precise conseguenze di natura giuridica per chi offre servizi di sicurezza e per chi li acquista.

Bisogna innanzi tutto dire che dal punto di vista dell’azienda non c’è quasi mai una soluzione apoditticamente migliore dell’altra. Viceversa è essenziale poter compiere una scelta consapevole che si integri accettabilmente nell’organizzazione interna. Se è vero, infatti, che la sicurezza è un processo e non un prodotto, allora non è pensabile “innestarla” tout-court in una struttura che ha già le proprie regole e che dovrebbero essere “sconvolte” il meno possibile.

Quale che sia la scelta operata è essenziale regolamentare contrattualmente il rapporto con il fornitore in modo da evitare che il servizio si trasformi in un capestro. Che, ad esempio, impedisce all’azienda-cliente di cambiare fornitore o tecnologia perché non c’è consapevolezza su quello che è stato fatto.

Altro elemento fondamentale da considerare è stabilire precise assunzioni di responsabilità a carico del fornitore, in ordine all’effettivo svolgimento di attività di debugging e patching, e in relazione alle tempistiche di rilascio delle modifiche. In altri termini, una volta “piazzata” l’applicazione o il sistema operativo, il fornitore non avrebbe alcun obbligo di continuare a testare i prodotti alla ricerca di vulnerabilità. Quindi, è necessario vincolarlo contrattualmente allo svolgimento di questo compito.

E’ poi utile garantirsi una rivalsa verso il fornitore per i danni provocati da bug e funzionalità non non documentati e non comunicati dal fornitore del software all’azienda-cliente. Dei quali, magari, si viene a conoscenza proprio tramite i servizi gratuiti come la nota mailing list Bugtraq. Da questo punto di vista, infatti, la full disclosure costituisce uno strumento molto utile per la gestione del contenzioso (arbitrale o giudizario) in materia. Mettendo il cliente in condizioni di contestare in modo preciso l’esistenza di un difetto del software e di chiedere adeguati risarcimenti.

E’, infine, opportuno, verificare preventivamente se i servizi offerti come basati su full disclosure siano di livello adeguato. Molti “consulenti”, infatti, non fanno altro che attingere parassitariamente alle fonti pubbliche e quindi sono in grado di erogare i propri servizi solo in dipendenza della disponibilità delle informazioni.

Come insegna Ulisse, prima di lasciarsi “affascinare” dal canto delle sirene, è meglio farsi legare fortemente all’albero della nave, altrimenti…

Per approfondire:

Full Disclosure is a necessary evil

http://online.securityfocus.com/news/238

MS to force IT-security censorship

http://online.securityfocus.com/news/277

Responsible Vulnerability Disclosure Process

http://www.ietf.org/internet-drafts/draft-christey-wysopal-vuln-disclosure-00.txt

Possibly Related Posts: