Results, not resolutions

La scorsa settimana Bill Gates ha diffuso una nota a
tutta l’azienda, definendo una nuova direzione strategica per la
Microsoft. In rapporto al cambiamento registrato quando l’azienda si è
"tuffata" nell’internet, Gates ha elevato la questione sicurezza
ai livelli più alti di priorità. Concentrando l’attenzione su quello che
ha definito "Trustworthy Computing," Gates progetta di
trasformare la Microsoft in un’azienda che produce software accessibile,
affidabile e sicuro. La fiducia non è un qualcosa che può essere
distribuito; deve essere acquisita. E la credibilità è un obiettivo
importante nell’informatica. Ma al contrario degli obiettivi basati sulle
performance o sugli elenchi di funzionalità, i progressi in questo
settore sono difficili da misurare.

Come possiamo determinare se una porzione di software sia più sicura di
un’altra? Oppure garantisce una migliore integrità dei dati rispetto ad
un altro? O ha una minore attitudine a contenere vulnerabilità non
scoperte? Come possiamo sapere Microsoft abbia veramente deciso di
dedicarsi alla sicurezza, o se tutto questo è soltanto un’altra
performance per la stampa e il pubblico?
Valutare la qualità della sicurezza non è così facile come misurare la
velocità di un processore o comparare le lista delle caratteristiche di
un software; e i problemi di sicurezza spesso non emergono durante il beta
test. Come esperti che operano da lungo tempo nel settore della sicurezza,
vorremmo suggerire alcuni criteri concreti per valutare i progressi di
Microsoft (e quelli di chiunque altro) verso lo sviluppo di un ambiente
sicuro.
Ci sono dei cambiamenti specifici e verificabili che vorremmo Microsoft
realizzasse. Non si tratta di una lista esaustiva: costruire software
sicuro richiede molto di più di quello che indichiamo qui. Il nostro
scopo è fornire una lista verificabile di raccomandazioni, in modo che la
comunità possa giudicare la sincerità della Microsoft. Alcune delle
nostre raccomandazioni sono più semplici da implementare rispetto ad
altre, ma se Microsoft ha un atteggiamento serio sulla sicurezza, diretto
a raggiungere una vera leadership, non può ignorare nessuna di queste.
Alcuni dei nostri suggerimenti sono più semplici da verificare degli
altri. Ma il nostro scopo è che ciascuno di questi sia del tutto
indipendentemente misurabile. Alla fin fine le dichiarazioni e comunicati
stampa non significano niente. Nella sicurezza quello che importa sono i
risultati. Se potessimo sintetizzare le nostre raccomandazioni in un solo
paradigma, sarebbe quello della semplicità. Le complessità e peggior
nemico della sicurezza, e sistemi sono caricati di funzionalità,
caratteristiche e opzioni sono molto meno sicuri di quelli semplici che
fanno poche cose in modo affidabile. Chiaramente Windows è e sempre
sarà, un sistema operativo complesso. Ma ci sono cose Microsoft può fare
per rendere anche un sistema operativo complesso più semplice e più
sicuro. Microsoft deve concentrare i propri programmatori sulla
progettazione software sicuro, sul "far bene" le cose fin
dall’inizio dei progetti.

I – Data/Control Path Separation

"Si dovrebbe facilitare agli sviluppatori la
comprensione e l’implementazione dei modelli di sicurezza. Che quindi
devono essere facili da capire e da implementare" Bill Gates memo

Uno dei modelli più semplici robusti e sicuri per
raggiungere questo obiettivo è applicare una rigida separazione fra dati
e codice. La commistione di dati e codice è responsabile della gran parte
dei problemi di sicurezza, e Microsoft è stata il peggiore offender della
rete. Ecco un esempio: originariamente la posta elettronica funzionava in
puro testo, il che rendeva impossibile la diffusione di virus tramite
questo strumento. Microsoft ha cambiato questo stato di fatto facendo in
modo che propri programmi eseguissero automaticamente istruzioni incluse
nei messaggi di posta. Questo ha spianato la strada a virus per e-mail
come Melissa e LoveBug , che si diffondono automaticamente verso le gli
indirizzi contenuti nella rubrica della vittima. Microsoft deve riparare
questo danno di sicurezza rimuovendo queste funzionalità dei propri
programmi di posta elettronica, e da molti altri dei propri prodotti.
Questa rigida separazione dei dati del codice richiede di essere applicata
a tutti prodotti. Microsoft ha aggravato il problema confondendo la
distinzione fra desktop e Internet. Questo ha provocato numerose
vulnerabilità alla sicurezza, basate su differenti parti del sistema
operativo che usano le risorse di sistema in modo differente. Microsoft
dovrebbe rivedere queste decisioni di progettazione.
Pensiamo che nella prossima versione dei propri prodotti, Microsoft
dovrebbe concentrarsi su due obiettivi: illustrare le azioni,e fornire un
ambiente protetto. Si dovrebbe concentrare soltanto sulla eliminazione
delle funzionalità insicure e sull’aggiunta di sicurezza.

Office: le macro non dovrebbero essere contenute in un
documento Office. Le macro dovrebbero essere archiviate separatamente,
come modelli, che non possono essere aperti come documenti. I programmi
dovrebbero fornire una interfaccia visuale che mostra all’utente quello
che fanno le macro, e dovrebbe consentire di fissare dei limiti a ciò che
macro non firmate dalla divisione informatica di un’azienda possono fare.

Internet Explorer: Internet Explorer dovrebbe supportare
una completa separazione di dati e controlli. Java e Java script
dovrebbero essere modificati in modo da non poter utilizzare programmi
esterni in modo arbitrario. ActiveX dovrebbe eliminare tutti i controlli
che sono etichettati come "sicuri per lo scripting."

E-mail: i programmi di posta elettronica non dovrebbero
supportare scripting (o quantomeno dovrebbero evitare di farlo come
opzione di default). Gli script di un messaggio di posta elettronica
dovrebbero essere allegati come attachment MIME separato e ci dovrebbero
essere limitazioni a ciò che macro non firmate dalla divisione
informatica di un’azienda possono fare.

.NET: dovrebbe avere una chiara definizione di cosa fare
e di cosa non fare. Grazie a Java, la comunità della sicurezza ha
imparato molto sulla sicurezza del codice mobile. Anche se il codice
mobile è molto pericoloso, non sarà eliminato. Ma perché il codice
mobile possa sopravvivere, dovrebbe essere riprogettato tenendo presente
la sicurezza come caratteristica primaria. Dovrebbe poi essere abbandonata
la implementazione di Microsoft SOAP un protocollo che gira
"sopra" al http in modo da poter aggirare i firewall.

II Configurazioni di default

"i nostri prodotti dovrebbero enfatizzare la
sicurezza già appena tirati fuori dalla scatola" – Bill Gates memo

Il software Microsoft, di base, si installa con molte
caratteristiche in più di quelle che la maggior parte degli utenti
richiede o vuole. Questo rende il software più vulnerabile del
necessario. Ci sono molti i recenti esempi di quanto asserito. Il recente
bug Universal Plug and Play funziona anche se si ignora cosa UPnP sia in
grado di fare, e a prescindere dal fatto che lo si utilizzi. Il Super
Cookie Bug in Wndows Media Player funziona anche se non si utilizza questa
applicazione. Code Red attacca con successo le installazioni IIS, anche
nelle installazioni in cui Windows non è utilizzato come webserver. In
più, le funzionalità dovrebbero essere installabili una per una. In
UNIX, per esempio, un web server e un ftp server sono separati e devono
essere installati separatamente. L’installazione di IIS, "posa in
opera" non soltanto un web server ma anche un ftp server, un Gopher
server, e lo stesso Bill probabilmente non sa che cos’altro. Inoltre non
è sufficiente dare gli utenti la possibilità di disattivare le
funzionalità non necessarie. Gli utenti non sanno nemmeno quali siano
quelle attive, e tantomeno sanno come disattivarle. Per non parlare del
fatto che funzioni disabilitate possono "tornare in vita"
accidentalmente. La migliore prevenzione per gli attacchi contro una certa
funzionalità software è che questa non sia presente in quel momento.

Raccomandiamo che la prossima versione di tutti prodotti
Microsoft venga installata automaticamente col minor numero di
caratteristiche e funzionalità possibile, e che quelle addizionali
richiedano una attività di installazione specifica per essere attivate.
Raccomandiamo inoltre che quest’installazione sia ben visibile per
l’utente, in modo di questi possa sapere esattamente che cosa sia stato
attivato. Raccomandiamo che Microsoft consenta di installare e
disinstallare tutte le funzionalità sia una per una, sia in un colpo
solo. Raccomandiamo di non installare ciò che non è necessario, invece
di "mettere su tutto" anche se disabilitato. Ulteriori controlli
dovrebbero essere implementati per consentire alla divisione informatica
di un’azienda di impedire l’installazione di certe funzionalità.

Raccomandiamo inoltre che .NET venga realizzata in modo
di usare le configurazioni provenienti da una grande varietà di fonti,
compresa Microsoft, i propri concorrenti, e gruppi di pubblico interesse
come la EFF.

III. Separazione di protocolli e prodotti

"Quanto più il software è diventato
complesso, interdipendente, e connesso, tanto più la nostra reputazione
come azienda è diventata più vulnerabile" Bill Gates memo.

Oggi Microsoft costruisce servizi grandi complessi che
includono molti servizi più piccoli. Per esempio, il protocollo Microsoft
per i file sharing, contiene oltre al file sharing, il registry sharing,
remote editing, printer sharing, password management, e molto altri. Se
l’utente vuole utilizzare uno di questi servizi deve installarli tutti. E’
necessario che tutto questo sia separato in singoli servizi, che girano in
parti distinte del software server, in modo che l’utente possa scegliere
cosa installare e dove. Se non si fa così, la complessità del software
cresce fino a raggiungere dimostrabili livelli di insicurezza. Anche in
questo caso raccomandiamo che Microsoft separi le funzionalità in modo
che l’utente possa installate soltanto quelle specifiche delle quali ha
bisogno. Raccomandiamo inoltre che Microsoft fornisca e consenta ad altri
fornire una varietà di funzioni preassemblate. Molti utenti non vogliono
installare le funzioni una per una e si fidano di altri che dicono loro
cosa di cui hanno bisogno.

IV costruire software sicuro

"Così ora quando siamo di fronte di una
scelta fra a giungere caratteristiche e risolvere problemi di sicurezza
dobbiamo scegliere la sicurezza" Bill Gates memo

Il software commerciale è pieno di difetti e alcuni di
questi non affliggono la sicurezza. Ma questa non è una scusa per
giustificare la storica apatia di Microsoft sul punto. Questi difetti sono
causati dalla cattiva qualità delle specifiche software detta della
progettazione e della realizzazione. Molto di quello che abbiamo discusso
cui sopra ha l’effetto di minimizzare l’impatto dei malfunzionamenti
riducendo la quantità di software su un computer. Ma anche così facendo
ne resterà comunque una gran parte e questo software richiede di essere
resistente ad attacchi. Questo significa che il software non dovrebbe
essere facilmente compromettibile una volta attaccato. E che anche se
fosse, il sistema nella sua interezza non dovrebbe crollare. Oggi dobbiamo
preoccuparci dal fatto che un singolo difetto in Windows renderà un
server totalmente insicuro, un singolo difetto in IIS metterà in pericolo
tutti i dati contenuti in .NET. Molto ancora potrebbe fare Microsoft per
raggiungere questo obiettivo e le nostre raccomandazioni potrebbero andare
avanti per pagine e pagine. Ma parlando in generale, dato che certe
funzionalità sono molto più fragili di altre, raccomandiamo quanto
segue: Microsoft dovrebbe abbandonare ogni programma di aggiornamento
automatico del software tramite Internet fino a quando questo non potrà
essere fatto in modo sicuro e affidabile. Oggi ci sono troppi problemi con
aggiornamenti e patch per consentire loro di funzionare senza che l’utente
ne sia conscio, e ci sono troppi problemi di autenticazione per prevenire
il fatto che qualcuno possa utilizzare queste funzionalità in modo
malizioso per attaccare un sistema. Microsoft dovrebbe eliminare ogni
database centralizzato dei propri e dei clienti dei suoi servizi .net.
Questi database sono troppo pericolosi da conservare in un unico posto. Le
conseguenze di una vulnerabilità in questo ambito sarebbero troppo
grandi. Microsoft si sta già muovendo verso la firma elettronica dei file
di codici. Mentre da un lato raccomandiamo che Microsoft prosegua in
questa direzione, suggeriamo anche che non si affidi alla firma
elettronica del codice come unico strumento di sicurezza. Codice firmato
non equivale infatti a codice sicuro, come ha dimostrato in qualche
occasione la comunità degli esperti di sicurezza quando si è occupata di
molte vulnerabilità di ActiveX. Microsoft dovrebbe abbandonare il
paradigma di sicurezza basato sulla firma del codice in favore di quello
" dei sacchi di sabbia". Oggi troppi componenti dei server
Microsoft ha girano con privilegi da amministratore. Quando un primo
servizio gira in questo modo è molto più facile che una deficienza della
sicurezza produca una totale compromissione del server. In ambienti UNIX,
i server sono spesso progettati per funzionare con privilegi di utente
normale. Questa dovrebbe essere la configurazione di base per tutti i
server Microsoft. Tutte le altre funzionalità introdotte da Microsoft
dovrebbero essere prese in considerazione ai fini della loro eliminazione.
Quelle che sono troppo rischiose dovrebbero essere rimosse fino a quando
non vengano riscritte e rese più sicure

V. Trasparenza e verificabilità

"Se esiste un qualche modo per proteggere meglio i
dati importanti e minimizzare i tempi di fermo macchina dobbiamo
concentrarci su questo" Bill Gates memo

Troppo dei sistemi operativi Microsoft funziona
invisibilmente e al di là della conoscenza dell’utente. Troppe delle sue
funzionalità opera senza lasciare traccia di quello che è accaduto. E
con le release successive dei sistemi operativi Microsoft è diventato
sempre più difficile per un utente tenere sotto controllo il proprio
sistema o esaminare che cosa questo stia facendo. Tutto questo ha delle
ramificazioni disastrose sulla sicurezza e dovrebbe essere cambiato.
Auspichiamo che Microsoft aggiunga delle potenti capacità di controllo
tutti sui prodotti sia sistemi operativi sia applicativi. Raccomandiamo
che Microsoft fornisca insieme al sistema operativo i relativi strumenti
di configurazione. E anche – a favore della divisione di informatica delle
aziende – gli strumenti per gestire le configurazioni dei propri computer.
Vorremmo anche assistere all’abbandono da parte di Microsoft del registro
di sistema in favore di un sistema più orientato all’utente e meno oscuro

VI Pubblicazione preventiva di protocolli e progetti

"Come azienda ci sono molti cambiamenti di cui
Microsoft ha bisogno per assicurare di mantenere la fiducia dei nostri
clienti ad ogni livello, dal modo in cui sviluppiamo software agli sforzi
per fornire supporto, alle nostre strategie operative e di
commercio." Bill Gates memo

Se c’è una cosa di esperti di sicurezza hanno imparato
nel corso di anni è che ogni sistema, alla prima uscita, avrà difetti di
sicurezza. L’unico rimedio affidabile è pubblicare i dettagli sul
funzionamento del sistema il più presto possibile è lasciarli esaminare
dalla comunità di esperti di sicurezza. Microsoft ha bisogno di
pubblicare le specifiche di protocolli anticipatamente e incoraggiare
commenti pubblici. Questo è doppiamente importante sia per la sicurezza
di protocolli, sia per quella dei sistemi. Se una porzione del software è
di importanza critica per la sicurezza, allora non c’è modo di
raggiungere l’affidabilità senza la preventiva pubblicazione. Che però
non garantisce la sicurezza, pur essendo una fase inevitabile del
processo. Non stiamo suggerendo che Microsoft rilasci tutti i diritti di
proprietà intellettuale sui protocolli e interfacce o consenta qualcuno
di implementare utilizzare i propri standard. Stiamo dicendo che
dovrebbero essere pubblici e non segreti. Le specifiche pubblicate
dovrebbero essere complete, leggibili, generalmente disponibili. Non solo
– perchè è insufficiente – a certi ricercatori o alle persone che hanno
firmato un accordo di riservatezza o hanno pagato per ottenere questo
privilegio. Non si tratta di una scelta semplice dal punto di vista
commerciale, ma se Microsoft è seriamente intenzionata a mettere la
sicurezza al primo posto, ha bisogno di entrare in contatto con la
comunità degli esperti di sicurezza piuttosto che ignorarla. E Microsoft
dovrebbe aspettare prima di implementare queste specifiche nei prodotti.
Raccomandiamo che tutti protocolli interfacce utilizzati dal software
Microsoft siano immediatamente pubblicati, e che sia stabilita una
moratoria di un anno su tutte le modifiche che non riguardano la
sicurezza. Oltre a suggerire di la pubblicazione di ogni nuovo protocollo
o interfaccia almeno un anno prima di implementarli nei prodotti. In
aggiunta a tutto questo suggeriamo che Microsoft prenda in considerazione
l’idea di rendere pubblico tutto il proprio codice sorgente. Non stiamo
sostenendo che Microsoft debba rendere i propri prodotti open source, ma
se realmente vogliono convincere tutti circa la loro conversione alla
religione della sicurezza, dovrebbero rendere il codice disponibile a
verifica. Onestamente non ci aspettiamo che Microsoft lo faccia. Sarebbe
un cambiamento culturale troppo grande anche solo perchè lo prenda in
considerazione.

VII entrare in contatto con la comunità

"I piani di retribuzione dei product enigneer di
Microsoft, come aumenti e bonus, saranno anche collegati a quanto sicuri
sono i prodotti loro gestiti" Articolo della Associated Press sul
Memo di Bill Gates, 150102

Collegare la sicurezza alla retribuzione è il miglior
modo per produrre un cambio culturale dentro Microsoft. Ma crediamo che
l’azienda debba fare di più e compensare non soltanto i propri dipendenti
ma anche i ricercatori che non ne fanno parte. Microsoft non può ancora
troppo lungo minacciare insultare o screditare i ricercatori indipendenti
che trovano vulnerabilità nel suoi prodotti. Microsoft ha bisogno sia di
controlli automatici della sicurezza sia di valutazioni condotte da
esperti di sicurezza. Una buona parte del lavoro in questo settore è
stato già fatto al di fuori della Microsoft. Auspichiamo che l’azienda
dedichi delle risorse ad una revisione generale della sicurezza di tutto
il proprio codice usando esperti di sicurezza dell’azienda e esterni ad
essa. Raccomandiamo inoltre che Microsoft crei un soggetto indipendente
per valutare le vulnerabilità riscontrate dai ricercatori esterni
all’azienda.

Conclusioni

"Alla fine il nostro software dovrebbe essere
tanto essenzialmente sicuro che clienti non dovranno nemmeno preoccuparsi
di questo" Bill Gates Memo

Le nostre raccomandazioni sono tutt’altro che esaustive.
C’è molto, molto di più sulla costruzione di software sicuro rispetto ai
sette punti che abbiamo indicato in questo articolo. Questi suggerimenti
devono essere considerati come riferimenti sul breve periodo; trattandosi
di indicazioni sull’implementazione e non sull’architettura. Il buffer
overflow, dal punto di vista comparativo, è un problema risolvibile ad un
facile livello di’implementazione. Livelli elevati, come l’implementazione
di uno scripting engine, o la messa in sicurezza della comunicazione fra
processi, sono argomenti molto più complicati. Ma se Microsoft non parte
con le cose più semplici, non sarà mai in grado di risolvere quelle
difficili.

La sicurezza non è facile, e non è qualcosa che puoi
aggiungere un prodotto a posteriori. Rendere la sicurezza la prima
priorità per Microsoft richiederà una riprogettazione dalle fondamenta
del modo in cui la compagnia produce e promuove il software. Tutto questo
coinvolgerà una difficile transizione culturale all’interno di Microsoft.
Richiedendole di mettere da parte profitti sul breve periodo per
raggiungere obiettivi sul lungo. E’ un obiettivo difficile e crediamo che
Microsoft possa farcela. Speriamo che azienda rimanga concentrata sul
raggiungimento di questi risultati.

Bruce Schneier is Chief Technology Officer of Counterpane
Internet Security Inc. Adam Shostack is Director of Technology at Zero-Knowledge Systems, Inc.

Possibly Related Posts: