Roma – La pubblicazione nei giorni scorsi di un documento sulla sicurezza e la gestione delle informazioni del manager della security in Microsoft, Scott Culp, ha sollevato un gran polverone, in Italia e all’estero.
Per questo abbiamo approfondito l’argomento con un noto Business IT Consultant romano, Stefano Tagliaferri, in una breve chiacchierata telefonica.
Punto Informatico: Stefano, nella sua analisi Culp prende spunto dalle invasioni di worm come Nimda o Code Red che hanno fatto miliardi di danni e colpito migliaia di computer e dalla condanna come criminale degli autori di quei worm.
Stefano Tagliaferri: Ma quali computer e piattaforme sono state colpite da questi worm? E quali dati avrebbero distrutto? Non se n’è mai parlato. Né mi risulta che sia stato identificato l’autore di quei codici e che ci sia stato un processo.
PI: Beh, Culp afferma che i worm hanno sfruttato vulnerabilità di sistema senza le quali non sarebbero esistiti…
ST: Ah, quindi tutti questi worm sfruttavano delle security flaws. Di chi è la responsabilità di queste security flaws? Di chi acquista il software o di chi lo scrive?
Il normalissimo e tanto disprezzato “buon senso” direbbe che è una responsabilità di chi scrive questi programmi e li pubblica in qualsiasi forma, remunerata o no. Quindi è una responsabilità del produttore, non dell’acquirente.
Nasce un problema: l’acquirente conosce i problemi che questi “security flaws” possono generare o ne è tenuto all’oscuro, perché non si vuole fare brutta figura, e quindi non vendere un prodotto, magari spacciato per “sicuro”?
PI: Culp ammette che l’industria può e deve sviluppare prodotti più sicuri anche se non è realistico che si arrivi alla perfezione.
ST: Il che vuol dire che finora questi aspetti non sono stati considerati per la loro reale importanza.
C’è differenza tra “perfezione” e il cercare di arrivarci. Si è almeno provato ad arrivarci? A giudicare dal numero elevato di security flaws di alcuni sistemi, sorge un dubbio molto serio.
PI: Ma Culp sostiene che tutti i software moderni contengono inevitabilmente dei bug, perché sono – afferma Culp – tra quanto di più complesso mai sviluppato dal genere umano.
ST: Ogni software può avere dei problemi, ma si può cercare di risolverli, con un’accurata fase di betatesting e facendo buon uso del feedback dei tester.
Problema n.1: entrambe queste due cose costano care, perché coinvolgono molto personale (coordinatore dei betatester, sorting del feedback e invio dello stesso ai responsabili di competenza ecc?), impongono un tempo maggiore per la commercializzazione di un programma e non aggiungono un valore tangibile al prodotto finale.
In questi tempi di serializzazione massificata, i produttori di software sono ancora disposti ad avere e gestire un feedback appropriato dei loro prodotti prima che vengano immessi sul mercato? Eppure questo aumenterebbe la sicurezza.
PI: Culp sostiene anche che la pubblicazione dei bug e delle vulnerabilità in certi casi può essere definita “anarchia informativa”. E che la pubblicazione delle istruzioni passo-passo per sfruttare certe vulnerabilità è irresponsabile.
ST: Che si vuole dire? Un amministratore di sistema, quindi in teoria una persona informaticamente evoluta, non ha il diritto di conoscere che cosa succede al suo sistema in certi casi?
Non ha il diritto di controllare se il suo sistema presenta queste anomalie?
PI: Culp afferma che queste informazioni si traducono nella fornitura di armi che permettono di colpire sistemi.
ST: Armi? Stiamo conducendo una guerra?
Il modo per non fornire queste cosiddette “armi” a questi cosiddetti “terroristi” non potrebbe essere quello di eliminare queste falle dai sistemi prima che vengano distribuiti?
: PI: Secondo te fornire una “ricetta” per sfruttare un certo bug aiuta gli amministratori di sistema? Secondo Culp no, anzi.
ST: Se c’è una vulnerabilità legata ad un servizio specifico, conoscendola posso o disabilitare quel servizio dove non è assolutamente necessario, o cercare una alternativa che non mi presenti quello specifico problema. Non siamo in un mondo in cui esiste un’unica scelta.
PI: Culp afferma che un amministratore di sistema non ha bisogno di conoscere la natura della vulnerabilità ma ha bisogno della patch contro quel bug, proprio come un individuo con il malditesta avrebbe bisogno di una cura ma non di conoscere la natura del suo malditesta?
ST: E’ un paragone decisamente fuorviante per diverse ragioni:
– perché un amministratore di sistema deve essere tacciato di ignoranza?
– perché al teorico “mal di testa” si suggerisce un solo rimedio, quando ce ne sono molti?
– Perché si vuole precludere all’amministratore di sistema la capacità di controllare e verificare che ciò che lui amministra funzioni come dovrebbe o come il vendor ha garantito?
A questo punto viene da chiedersi se il cosiddetto “amministratore di sistema” debba avere una intelligenza sua propria o no.
Mi scuso se questo può suonare offensivo a questa categoria, ma non è una mia definizione.
PI: Culp afferma che non tutti gli amministratori di sistema hanno utilizzato le patch fornite dai produttori contro specifiche vulnerabilità, finendo dunque per caderne vittime.
ST: E qui purtroppo si chiarisce il problema degli amministratori di sistema.
Come mai solo pochi hanno applicato queste patch? Perché pochi si interessavano anche all’aspetto della sicurezza dei propri dati? Perché molti amministratori di sistema sono così ignoranti da non capire la portata ed il valore di quello che amministrano?
Verifichiamo chi qualifica talune persone ad essere definite “amministratori di sistema”.
Si possono definire veramente tali coloro che non comprendono a fondo il sistema che amministrano?
Quando suona un allarme alcuni lo ignorano per i più disparati motivi.
Ci sono admin che non capiscono il significato di un allarme oppure a volte non sanno minimamente cosa sia un allarme ed un log di sistema, ma è anche possibile che ignorino i problemi visto che hanno troppe attività da svolgere oppure, caso limite tipicamente italiano, la sicurezza informatica non rientra nei budget dell’azienda perchè costa troppo.
PI: Culp sostiene che con la sua proposta non si vuole limitare la libertà di parola ma solo evitare che qualcuno continui a gridare al fuoco nel mezzo di una platea al cinema.
ST: Bel paragone. E se c’è veramente l’incendio nel cinema, che si fa? Lo si sussurra dolcemente alla fidanzata a fianco, e si esce piano piano così da non far insospettire le persone altrimenti poi la gente si alza tutta insieme e intasa l’uscita?
PI: Culp auspica un rapporto più stretto tra chi scopre i bug e i produttori, che si danno da fare per risolvere le vulnerabilità non appena scoperte.
ST: Qui c’è un piccolo problema: il produttore non si dà da fare velocemente per risolvere questi problemi. Anzi, a volte certe vulnerabilità sono girate in Bugtraq (celebre mailing list sulla security, ndr) per lungo tempo senza che venisse rilasciata una patch.
Se un certo tool o una applicazione che può essere dannosa o a rischio circola lo stesso, forse è perchè il produttore fa orecchie da mercante. Anche qui torna un aspetto già visto prima: la sicurezza di un sistema è messa nel conto sia di chi lo produce che di chi lo acquista? Molte volte sembra di no. E allora, per chi non ne comprende l’importanza da sé, arriva la lezione “hard way”.
PI: Culp ritiene che una parte del problema si risolverebbe se le imprese precisassero le proprie policy sulla sicurezza aziendale quindi i clienti potessero scegliere i consulenti sulla sicurezza chiedendo loro la propria posizione rispetto al problema dell’anarchia dell’informazione. E i professionisti della sicurezza secondo Culp devono solo esercitare un autocontrollo.
ST: Perché le aziende non dovrebbero invece scegliere accuratamente i loro amministratori di sistema in base alle competenze che essi dimostrano sul campo, e non solo su un pezzo di carta? Per quello che mi compete, credo fortemente che i professionisti o gli studiosi della sicurezza hanno tutto il diritto di pubblicare le loro scoperte, come del resto lo ha qualsiasi altro ricercatore in ogni campo scientifico o umanistico.
Sta agli altri, quindi anche i sysadmin, saper trarre i frutti di queste pubblicazioni leggendo, studiando, comprendendo e agendo di conseguenza.
Purtroppo, per fare tutto ciò, c’è bisogno di gente che pensa, e questa non mi sembra una caratteristica desiderata da Mr. Pulp. Decidiamo sin da ora a chi delegare la nostra sicurezza informatica.
Credo che senza la cultura Hacker e la cosiddetta “security community” non si sarebbe mosso un dito da parte dei produttori per tappare le falle e mi domando se lasciare tutto nella mani della comunità dei produttori di software sarebbe poi davvero un comportamento responsabile.
Intervista a cura di Paolo De Andreis
Ti potrebbe interessare
22 ott 2001