Prendo spunto da questo post, nel quale leggo alcuni commenti a un face-off fra Schneier e Ranum. Essenzialmente, Schneier è favorevole alla “vulnerability research”, nella logica aperta tipica della ricerca seria sulla crittografia, dichiaratamente contraria alla “security through obscurity”. Ranum invece sostiene sostanzialmente la posizione per cui l’attenzione al cercare vulnerabilità non posta a miglioramenti significativi nella qualità dei sistemi. Sono assolutamente d’accordo con il poster, entrambi esprimono dei punti validi ma fra le due posizioni quella di Ranum è più solida. Si vede chiaramente che Schneier viene dalla crittografia, mentre Ranum viene dalla sicurezza delle reti. Non ripeto le considerazioni dell’articolo o del post, ma ne vorrei aggiungere qualcuna.
Una funzione fondamentale della ricerca e pubblicazione di vulnerabilità, che Schneier si è dimenticato di citare, è quella di fare da “cane da guardia” rispetto alle aziende che producono software. Queste non hanno in generale interesse a investire nella sicurezza dei loro prodotti, che è un costo che non da funzionalità “visibili”, e anzi tendono per ovvie ragioni di marketing a sminuire i problemi. Quello che porta veramente l’attenzione sul problema non è l’esistenza degli attacchi ma la pubblicazione degli errori, specialmente se grossolani. La “full disclosure” non è sempre esistita: è nata nella prima metà degli anni ’90 come risposta ad un’industria che metodicamente trascurava la sicurezza, sminuiva i problemi con assurdi “fattori mitiganti” e non forniva informazioni se non come forma di marketing. E parlando di “fattori mitiganti” non mi riferisco a Microsoft, che pure fa un uso abbondante di questo concetto: Microsoft all’inizio degli anni ’90 non aveva un ruolo di rilievo nello sviluppo di Internet. Mi riferisco invece soprattutto ai grossi produttori di sistemi Unix e Unix-like, nonché a molti progetti di software “indipendenti” tipo sendmail. Credo di aver avuto già occasione di dire che la mailing list Bugtraq è nata proprio in conseguenza di uno di questi episodi. Vado a memoria: un baco di sendmail particolarmente critico era in una parte del codice che molti vendor avevano modificato nelle versioni per i propri sistemi. Dopo infinite discussioni e informazioni parziali o fuorvianti, qualcuno (non ricordo chi) ha pubblicato se ben ricordo su “firewalls” un proof-of-concept che finalmente ha permesso di capire quali versioni fossero le versioni vulnerabili. Sulla mailing list ci sono state però proteste per la pubblicazione e quindi è nata Bugtraq proprio per poter pubblicare queste informazioni. Non c’è da dubitare che in assenza della continua pressione causata dalla pubblicazione delle vulnerabilità, si tornerebbe alla situazione di disinteresse da parte dei vendor e di informazioni fuorvianti dei primi anni ’90.
Tuttavia, ha certamente ragione Ranum: l’attenzione alla “vulnerabilità”, che spesso si riduce oltretutto al baco software, è eccessiva ed ha portato a questa continua corsa alla patch come strumento principale per correggere i problemi di sicurezza, anziché a ragionare sul progetto. E forse, la cosa va letta tenendo presente quanto detto sopra: sui bachi i produttori vengono messi pubblicamente sotto pressione, sulla progettazione no. Microsoft può essere la controprova di questo concetto, perché è l’unica che è stata messa sotto pressione realmente e pubblicamente (ovvero, in un modo comprensibile al grande pubblico) per cattiva progettazione dal punto di vista della sicurezza, e mi sembra che sia l’unica che ha di conseguenza reso pubblici (ovvero, di nuovo, quasi comprensibili al grande pubblico) i propri sforzi in senso progettuale, in particolare con Vista, e che si è quindi esposta anche a critiche e discussioni pubbliche sulla qualità del progetto. Forse la strada per migliorare realmente la sicurezza dei sistemi è proprio questa, riuscire a rendere “pubblica” la discussione sui difetti delle architetture e non solo sulle vulnerabilità.
Ma non era questo il tema che volevo inizialmente affrontare, bensì quello della capacità della ricerca di vulnerabilità di fornire indicazioni su come realizzare sistemi migliori. Sono d’accordo con Ranum sul fatto che questa capacità è minima, ma non solo per le questioni principalmente “di mercato” di cui parla Ranum.
Il problema è che disegnare un sistema sicuro e trovarne le vulnerabilità in un sistema in esercizio sono due competenze diverse. Entrambe le attività richiedono la “mentalità della sicurezza”, che come dice giustamente Schneier è innaturale per chi è abituato a cercare di far funzionare le cose. È il tipo di mentalità che porta a cercare di capire come possono “non funzionare” le cose, come trovare difetti. Dice Schneier: This mindset is difficult to teach, and may be something you’re born with or not. But in order to train people possessing the mindset, they need to search for and find security vulnerabilities–again and again and again. Una mentalità che è difficile da insegnare o da imparare senza la ricerca attiva di vulnerabilità. Security engineers see the world differently than other engineers. Instead of focusing on how systems work, they focus on how systems fail, how they can be made to fail, and how to prevent–or protect against–those failures. Disegnare sistemi senza tenere conto di questo approccio vuole dire concentrarsi su come far funzionare le cose, impostazione che aiuta poco dal punto di vista della sicurezza. Il risultato sono sistemi che sembrano perfetti se si segue la logica (e le spiegazioni) di chi li ha disegnati, e che poi rivelano i loro limiti ad un’analisi nell’ottica del “come non farli funzionare” . Ed è per questo che si dice sempre che la sicurezza va messa dall’inizio, perché questa logica deve essere parte della progettazione. La sicurezza non può essere né una collezione di “funzionalità di sicurezza” né una serie di toppe a posteriori. Ma attenzione, ricerca di vulnerabilità e “bucare i sistemi” sono due cose diverse. Good cryptographers discover vulnerabilities in others’ algorithms and protocols. Good software security experts find vulnerabilities in others’ code. Good airport security designers figure out new ways to subvert airport security. And so on. È chiaro che scaricare un tool da Internet e usarlo per bucare un sistema non insegna niente, mentre invece non è necessario attaccare i sistemi degli altri per acquisire questa mentalità.
Tuttavia, al di là della “mentalità della sicurezza”, attaccare i sistemi e progettarli sono due attività molto diverse, e richiedono competenze diverse, non basta la mentalità della sicurezza. Io tendo a fare il paragone con le casseforti. Allo scassinatore non basta sapere che se la cassaforte ha un certo meccanismo allora basta fare un buco in un certo punto per aprirla: deve conoscere i singoli modelli e sapere in pratica esattamente dove va fatto il buco. E se con un’altra serve invece sentire determinati rumori, deve avere la pratica per sentirli. E deve sapere anche che in alcuni casi basta una mazza molto pesante. Insomma, serve appunto la pratica. Per quanto riguarda i sistemi, deve saper utilizzare le tecniche (che non sono semplicemente i tool) e tenersi aggiornato costantemente su versioni, vulnerabilità e trucchi. Questo non farà però di lui una persona capace di progettare casseforti sicure, al più potrà dare indicazioni su errori da evitare. Allo stesso modo, la mentalità della ricerca di vulnerabilità porterà a dare indicazioni del tipo “fate la validazione dell’input”, una logica di rattoppo che non entra nel merito del progetto. Disegnare un sistema sicuro è tutt’altra cosa. Il progettista di casseforti non necessariamente ha la mano di velluto, e magari una mazza da cinque chili non la alza neppure, ma oltre ad avere la mentalità giusta deve sapere cosa serve per disegnare una cassaforte. Nel caso del software ad esempio, deve sapere che gli errori nel software ci sono sempre e deve sapere come minimizzare gli effetti di un errore di validazione dell’input. Della differenza fra “scrivere codice senza errori” e “disegnare software sicuro” ho già parlato qui, prenendo postfix come esempio, ma lo stesso discorso vale per i sistemi e le procedure, non solo per il software. Insomma, disegnare sistemi sicuri richiede di saper disfare ma anche di saper costruire in sicurezza, e questo è uno dei motivi principali per cui è così difficile trovare sistemi e prodotti sicuri, ed è anche il motivo per cui saper bucare sistemi non basta. In effetti, sistemi mal disegnati e poco attenti alla sicurezza sembrano essere in grado di produrre una quantità praticamente illimitata di vulnerabilità, tanto che trovarne una e correggerla sembra avere un impatto trascurabile sulla sicurezza complessiva.
Nello stesso tempo, la verifica autorizzata e pianificata delle vulnerabilità serve comunque, perché fra un buon progetto e una buona realizzazione c’è comunque molta strada; ma le toppe servono se il progetto è buono.
