Security Blog di Feliciano Intini : 3.1-Security Development Lifecycle (SDL)

Security Advisory 954462: nuovi tool per identificare le vulnerabilità che espongono ad attacchi SQL injection

Feliciano Intini — Wed, 25 Jun 2008 08:47:36 GMT

Due mesi fa vi avevo parlato di nuove ondate di attacchi di tipo SQL Injection , poi un mese fa ho ritenuto utile riaccennare al problema durante il video-editoriale su SQL Server (per chiarire che questo tipo di attacchi non sfruttano specifiche vulnerabilità...(read more)

Ancora sulla presunta superiorità del software Open Source nella gestione delle vulnerabilità: un bug fossile e il lancio di oCERT

Feliciano Intini — Wed, 14 May 2008 14:13:02 GMT

Lungi da me scendere nell'arena delle guerre di religione (mi conoscete ormai, no?), ma un paio di articoletti letti in questi giorni mi spingono a riprendere il tema del confronto sugli aspetti di sicurezza tra Windows e il software Open Source. Questi due articoli, a mio parere, confermano le considerazioni che ho fatto in un mio post recente (che ha ovviamente scatenato un picco di commenti...) in cui confutavo quello che continuo a sentire come uno dei motivi principali, se non addirittura l'unico motivo di chi proclama la presunta superiorità del software Open Source in area sicurezza: l'ispezionabilità del codice come garanzia di minori vulnerabilità. Scusatemi se mi cito da solo, avevo detto:

"...con tutto il rispetto per le community open source (che ammiro), ma il fatto che ci siano tanti che possano fare una revisione di sicurezza di codice open, non è assolutamente equivalente a dire che tanti facciano davvero tale revisione e altrettanti siano in grado di farla bene."

Eccovi i due articoli che supportano il mio punto di vista:

Developer reveals 25 year old software bug

A Swiss developer seems to have confounded the theory that open source software is the quickest to be patched, by revealing a bug in the BSD software distribution which has remained unpatched for at least 25 years. Advocates of open source software argue that because of the large number of people working on such projects, bugs are quicker to spot and patch. But developer Marc Balmer's efforts have seemingly proved the opposite. He reported the filesystem bug in his blog on Saturday. "Much to my surprise, I not only found this problem in all other BSDs or BSD-derived systems like Mac OS X, but also in very old BSD versions," Balmer wrote. "The bug has been around for roughly 25 years or more."

E' solo uno spunto per sorridere e riflettere: non sto dicendo che anche nella piattaforma Windows non vi siano bug fossili come questo, ma davvero, siamo tutti nella stessa barca...

Per strapparvi un altro sorriso: non mi venite a dire che lo sviluppatore ha segnalato questa scoperta perché sotto sotto è il cugino di Steve Ballmer visto il cognome che si ritrova...

Il secondo articolo è relativo al lancio dell'iniziativa oCERT (Open Source Computer Emergency Response Team):

Response team boosts open-source security

IT managers often assume that open-source software is more secure than proprietary commercial software. Anyone who uses open source can examine the original code to spot any lurking vulnerabilities, and potentially even fix the vulnerabilities themselves. With proprietary software, you have to trust the vendor to do it all for you. But open source's supposed security advantage assumes three things: 1) someone is actually looking at the code, 2) security vulnerabilities are getting reported and fixed, and 3) information about those fixes makes its way to Linux distributors and other software vendors, which apply the fixes to their products. But what things aren't happening? As a customer, how can you be sure?

Se si riconosce la necessità di una iniziativa come l'oCERT per consolidare centralmente le segnalazioni delle vulnerabilità e agevolare l'inserimento delle relative correzioni in tutte le possibili distribuzioni si sta implicitamente ammettendo che il processo di gestione delle vulnerabilità del modello collaborativo Open Source così come è ora non è poi così infallibile e garanzia di maggiore sicurezza...

Quindi, intanto sono benvenute le iniziative come l'oCERT che contribuiscono a migliorare i processi tipo SDL anche in ambito Open Source, e se qualcun altro mi parla di "many eyeballs lead to secure code"... lo prendo a morsi!

Share this post :

Nuova ondata di attacchi SQL Injection/iFrame: l'importanza della sicurezza applicativa e del security patching

Feliciano Intini — Mon, 28 Apr 2008 14:05:02 GMT

La blogosfera "sicura" (nome scherzoso con cui identifico l'insieme di blog/e-magazines in tema sicurezza che cerco di leggere quotidianamente) ha già ampiamente battuto questa notizia, e quindi dovreste essere già tutti consapevoli di quanto sto per riportarvi, ma in questo caso ho deciso che fosse giusto il "melius abundare" e unirmi al coro per ribadire alcuni concetti forse ovvi ai più esperti ma indubbiamente utili per comprendere come si sta evolvendo lo scenario di rischio su Internet.

E' in corso una nuova ondata di attacchi SQL Injection/iFrame che sta coinvolgendo progressivamente alcune centinaia di migliaia di siti web.

Intanto è importante sottolineare, come già fatto dal blog del MSRC, che questi attacchi non stanno sfruttando la vulnerabilità segnalata nel recente security advisory e tanto meno stanno sfruttando vulnerabilità già note relative alla piattaforma Microsoft (e quindi già corrette, con tanto di security patch risolutiva già disponibile): gli attacchi sono di tipo SQL Injection, come ribadito dal post sul blog di IIS al riguardo (dove potete trovare una ricca serie di link di approfondimento alle best practice di protezione rispetto a questo tipo di problematiche).

Questo mi porta a fare la prima considerazione: l'importanza fondamentale della sicurezza applicativa rispetto all'evoluzione del cosiddetto Web 2.0. Come riportato dal post di F-Secure, l'aumento di soluzioni web che accettano dei dati in ingresso direttamente forniti dagli utenti (blog, forum di discussione, moduli di feedback, e così via...) e il contemporaneo utilizzo dei server SQL nel backend di tali soluzioni, espone inevitabilmente ad attacchi di SQL injection se tali dati non vengono verificati prima di essere memorizzati. Quindi non basta aggiornare i sistemi web server con le patch di sicurezza di TUTTO il software che ci gira su: è doveroso anche assicurarsi di aver scritto codice sicuro per tutto il codice custom che viene eseguito da tali web server. Questo per quanto riguarda le responsabilità degli amministratori dei web server.

Guardiamo poi in breve alla dinamica con cui si sviluppano questi attacchi (descritta con qualche dettaglio in più dagli ultimi due post del blog di Panda Security, qui e qui): la compromissione dei web server di cui detto si realizza con l'aggiunta di uno script a tutte le pagine web; il malcapitato utente che atterra su questi siti che ritiene sicuri (mentre sono stati "infettati") esegue lo script e viene dirottato inconsapevolmente verso alcuni siti web sotto il controllo di questi pirati informatici (fino ad ora si segnalano 3 domini, nmidahena.com, aspder.com e nihaorr1.com che sarebbe utile filtrare sui vostri proxy). Tali siti eseguono del codice che è in grado di installare del malware sul vostro computer se questo viene trovato vulnerabile ad una serie di vecchie vulnerabilità per cui esiste già la patch (un esempio di quelle che sembrano essere utilizzate: MS06-014, MS07-004, MS07-018, MS07-033, MS07-055).

Seconda considerazione: il security patching urgente è una best practice che non si deve abbandonare mai. Per le aziende questo vuol dire dotarsi di processi di patch management che non siano ostacolati da troppa burocrazia e di strumenti che abilitino alla distribuzione rapida ed estesa degli aggiornamenti di sicurezza. Per gli utenti finali questo vuol dire assicurarsi di aver abilitato l'automatismo degli aggiornamenti di sicurezza, sia per i prodotti Microsoft che per tutti quelli che lo prevedono (e di operare una revisione periodica del livello di aggiornamento di quelli che non lo prevedono: esempio, WinZip). Un PC perfettamente aggiornato non è attaccabile in modo silente e l'unico rischio residuo rimane quello del consenso da parte dell'utente all'installazione di quanto questi siti pericolosi possano proporre in modo più o meno subdolo.

Share this post :

Analisi di rischio sui Bollettini di sicurezza Microsoft - aprile 2008

Feliciano Intini — Tue, 08 Apr 2008 23:05:08 GMT

L'emissione dei bollettini di questo mese, anche se risulta corposa con i suoi 8 bollettini che risolvono un totale di 10 vulnerabilità, si presenta con caratteristiche di insieme che non rendono lo scenario di rischio diverso dal livello medio (e sinceramente non particolarmente preoccupante) a cui Microsoft ci ha abituato da diversi mesi a questa parte: tutte le vulnerabilità risolte non erano note prima di questo rilascio e nessuna presenta caratteristiche tali da permettere la realizzazione di malware di tipo worm. Inoltre, come già accennato nel preavviso di venerdì scorso, il minor impatto delle versioni più recenti di Windows continua a confermare la validità del processo di Security Development Lifecycle (SDL) di revisione del codice dal punto di vista della sicurezza:

Windows Server 2008 e Windows Vista SP1 interessati da 4 bollettini
Windows Vista RTM interessato da 5 bollettini
Windows XP, Windows Server 2003 e Windows 2000 interessati da 6 bollettini.

Due aspetti meritano di essere segnalati questo mese:

il bollettino MS08-023 rappresenta l'inizio di un nuovo approccio: a partire da questo mese le modifiche dei Kill Bit relativi a controlli ActiveX vulnerabili sia di Microsoft che di terze parti non saranno più incluse nel tipico bollettino cumulativo di Internet Explorer ma distribuiti in un aggiornamento separato che sarà a sua volta cumulativo d'ora in avanti. In questo modo si agevola il cliente nella gestione dei test di compatibilità applicativa e si contribuisce al miglioramento degli aspetti di sicurezza dell'ecosistema delle aziende partner grazie alla possibilità di utilizzare in modo più esteso gli automatismi di aggiornamento per distribuire le segnalazioni di vulnerabilità anche di ActiveX relativi a prodotti non-Microsoft.
il bollettino cumulativo di Internet Explorer (MS08-024) presenta una importante modifica di funzionalità: è stato introdotto l'Automatic Component Activation per rimuovere il comportamento (fastidioso) che richiedeva agli utenti di cliccare sui controlli ActiveX di una pagina web prima di poterli effettivamente utilizzare (modifica introdotta nell'aprile 2006).

Maggiori dettagli sulle vulnerabilità:

MS08-018 su Project: una vulnerabilità Critical di tipo Remote Code Execution che permetterebbe di eseguire codice non autorizzato nel contesto di sicurezza dell'utente loggato tramite l'apertura di file di Project malformati ad-hoc. Le versioni più recenti di Project non sono interessate da questa vulnerabilità.
MS08-019 su Visio: due vulnerabilità di tipo Remote Code Execution che permetterebbero di eseguire codice non autorizzato nel contesto di sicurezza dell'utente loggato tramite l'apertura di file di Visio (per la prima vulnerabilità) e di file di Autocad di tipo .DFX (per la seconda vulnerabilità)malformati ad-hoc. La severity aggregata è Important.
MS08-020 sul DNS Client di Windows: una vulnerabilità Important di tipo Spoofing che permetterebbe di inviare al sistema sotto attacco delle risposte DNS malformate in modo tale da dirottare il traffico Internet verso sistemi illegittimi. Windows Vista SP1 e Windows Server 2008 non sono interessati da questa vulnerabilità.
MS08-021 sul componente GDI di Windows: due vulnerabilità Critical di tipo Remote Code Execution che permetterebbero di eseguire codice non autorizzato nel contesto di sicurezza dell'utente loggato tramite l'apertura di immagini di tipo WMF/EMF (per la prima vulnerabilità) e di immagini di tipo EMF (per la seconda vulnerabilità) malformate ad-hoc.
MS08-022 su VBScript/JScript di Windows: una vulnerabilità Critical di tipo Remote Code Execution che permetterebbe di eseguire codice non autorizzato nel contesto di sicurezza dell'utente loggato, con contenuti web acceduti via Internet o fruiti tramite email HTML come vettori di attacco. Windows Vista e Windows Server 2008 non sono interessati da questa vulnerabilità.
MS08-023 sull'ActiveX hxvz.dll in Windows e sull'ActiveX di Yahoo! Music Jukebox: una vulnerabilità Critical di tipo Remote Code Execution che permetterebbe di eseguire codice non autorizzato nel contesto di sicurezza dell'utente loggato, con contenuti web acceduti via Internet o fruiti tramite email HTML come vettori di attacco.
MS08-024 su Internet Explorer in Windows: classica cumulativa che risolve una vulnerabilità Critical di tipo Remote Code Execution, con privilegi sfruttabili pari a quelli dell'utente loggato e con contenuti web acceduti via Internet o fruiti tramite email HTML come vettori di attacco.
MS08-025 sul Kernel di Windows: una vulnerabilità Important di tipo Elevation of Privilege che permetterebbe, ad un utente con valide credenziali di logon sul sistema Windows, di eseguire un'applicazione ad-hoc in grado di essere eseguita con i massimi privilegi.

Ho anche aggiornato il mini-portale tematico che raccoglie le risorse sui Security Bulletin.

Share this post :

Quale, tra Windows, Mac OS e Linux, è il sistema più sicuro?

Feliciano Intini — Tue, 01 Apr 2008 12:36:47 GMT

Il mio post di ieri sulle problematiche di sicurezza di Apple e quello letto oggi su Punto Informatico, hanno riacceso l'idea che vi avevo lanciato nel mio post di Natale, quando vi promettevo che vi avrei parlato della inconfrontabilità tra i sistemi operativi che competono tra loro sul mercato, ora essenzialmente Windows, Mac OS e Linux. All'inizio della mia esperienza in Microsoft, da puro tecnico e con la testa ancora presa dal sacro fuoco della teoria accademica, non capivo bene perché non si affrontasse il raffronto tra sistemi operativi concorrenti in termini strettamente tecnici e di architettura, e di confronto di funzionalità di sicurezza. Dopo un po' di anni a lavorare sul fronte e in trincea sugli aspetti di sicurezza, a fianco dei clienti (grandi clienti, con reparti IT sterminati...) impegnati ad usare realmente i prodotti Microsoft per realizzare soluzioni di business, ho piano piano capito perchè il mio punto di vista iniziale, "da smanettone", era limitato.

Tra parentesi, ci tengo a farvi presente che è proprio questo atteggiamento limitato da semplice smanettone, che vede il suo mondo iniziare e finire al solo computer (o ai soli computer) che ha a casa nello suo piccolo (o grande) laboratorio, che è spesso alla base delle guerre di religione a cui assistiamo... (Ho la massima ammirazione per gli smanettoni di questo tipo, ma spesso è proprio da alcuni di loro che vedo un atteggiamento ottuso di guerra preconcetta...)

Vi riporto le tre considerazioni importanti che sono alla base della mia idea di essenziale inconfrontabilità, parzialmente emerse anche da alcune considerazioni che condivido dell'articolo di Annunziata su Punto Informatico (ci sono anche diverse considerazioni che non condivido, ma su queste ci torno su a breve...;-).

Lo scenario di rischio che vivono i diversi sistemi operativi concorrenti è profondamente diverso in virtù della diversa quota di mercato e della diversa appetibilità dei dati da carpire. Si può confrontare un sistema operativo client adottato da milioni di utenti con altri diffusi molto molto meno? Non credo proprio. L'interesse da parte di chi intende attaccare è per forza orientato verso le piattaforme più diffuse e che possono far ottenere maggior guadagno con minor investimento possibile in termini di ricerca. L'attenzione e la ricerca di vulnerabilità è per forza sbilanciato verso la piattaforma Microsoft che ha un mercato molto molto più appetibile.

Altra piccola parentesi: è bene anche tener presente che (ed è uno dei trend attuali più importanti) quando l'intento diventa criminale e l'approccio professionista per puntare alla compromissione di un sistema ben focalizzato, non c'è piattaforma o investimento che tenga... il gioco di attacco/difesa è molto più arduo ed estremo...

Intanto una considerazione su questo punto: il fatto che la piattaforma Microsoft sia nell'occhio del ciclone più di altri non sempre è un punto a sfavore. Sono convinto che la massiccia diffusione dei sistemi e l'estrema attenzione di chi cerca di bucare Windows siano la migliore piattaforma di security testing che ci sia, molto molto meglio della famosa "many eyeballs lead to secure code" cara ai sostenitori open source. Fatemi dire una volta per tutte cosa penso al riguardo: con tutto il rispetto per le community open source (che ammiro), ma il fatto che ci siano tanti che possano fare una revisione di sicurezza di codice open, non è assolutamente equivalente a dire che tanti facciano davvero tale revisione e altrettanti siano in grado di farla bene.

La fruibilità da parte degli utenti meno tecnici e la gestibilità dei computer in ambienti aziendali è notevolmente diversa tra questi sistemi operativi concorrenti. Per l'ambito in cui sono nati e per la storia evolutiva che stanno vivendo, solo ora questi diversi SO cominciano ad essere lontanamente paragonabili, ma la strada è ancora lunga: facilità d'uso, estetica accattivante, ricchezza di applicazioni e di periferiche, gestibilità della configurazione remota in ambienti numericamente complessi, possibilità granulare e semplificata di configurazione delle opzioni, ogni SO ha un suo profilo più o meno marcato su questi aspetti e quindi soddisfa esigenze diverse.

Le dinamiche di produzione dei sistemi operativi e delle funzionalità informatiche al contorno (hardware e software) sono diverse. Microsoft fa solo software e abilita l'ecosistema di partner nel realizzare hardware (e quindi driver: è di Microsoft la responsabilità dei driver???) e software. Apple fa il software ma controlla parte dell'hardware su cui fa eseguire il suo OS. Linux ha un modello di sviluppo del software totalmente diverso e per certi versi destrutturato (con il rischio di sfuggire al governo dei tipici processi di revisione di codice sicuro). Sono confrontabili questi sistemi? Direi di no.

Queste considerazioni mi portano a dire che la domanda "qual'è il sistema più sicuro?" messa così secca, non ha molto senso (come la sintesi finale dell'articolo di Punto Informatico...). Un sistema maggiormente preso di mira dagli attacchi non vuol dire che sia più insicuro, se mostra di riuscire a proteggere gli utenti e soddisfa i loro requisiti (che possono essere di facilità d'uso e ricchezza di dotazione hardware/software per Windows, altrettanta semplicità d'uso e superba estetica da parte di Apple, o estrema versatilità di configurazione e personalizzazione per l'utente smanettone nei riguardi dei sistemi Linux).

Il punto è, semmai, quali dei modelli di sviluppo e dei processi reali di produzione del software di questi diversi sistemi operativi è quello che offre maggiori garanzie di riduzione del livello di rischio in termini di riduzione vulnerabilità, miglioramento delle funzionalità protettive, maggiore supporto agli utenti nelle situazioni decisionali che sono legate ad aspetti di sicurezza, e capacità di reazione alle emergenze di sicurezza dal punto di vista gestionale? C'è carne al fuoco per diverse decine di post...

Share this post :

Non godo dei tempi duri che sta attraversando la sicurezza di Apple...

Feliciano Intini — Mon, 31 Mar 2008 12:34:34 GMT

Chi di voi mi segue assiduamente (grazie!) può testimoniare che questo blog ha da sempre evitato fermamente di scivolare in facili guerre di religione sulla superiorità di questo o quel sistema operativo rispetto alle problematiche di sicurezza. Avrei potuto tante volte riportarvi i report di vulnerabilità del CERT sulle piattaforme concorrenti di Microsoft per tentare di equilibrare l'evidente squilibrio di enfasi che la stampa pone sulle vulnerabilità Microsoft rispetto al disinteresse verso quelle non-Microsoft, ma ho sempre tralasciato questo atteggiamento di "marketing" negativo, preferendo sempre di gran lunga raccontarvi tutti i grandi progressi che Microsoft sta realizzando sul tema sicurezza, passo dopo passo, da quando (negli anni 2000-2003) ha dovuto reagire a quell'importante danno di immagine e di credibilità provocato dalla diffusione dei temibili worm (CodeRed, Nimda, Slammer, Sasser...). Questo lungo preambolo mi serve per ribadire ulteriormente che il fine con cui vi segnalo queste due notizie sulle problematiche di sicurezza che sta affrontando la piattaforma Apple non è quello di chi, come direbbe Confucio, "seduto sulla riva del fiume vede finalmente passare il cadavere di uno dei suoi nemici...".

Prima notizia: quasi sicuramente avete tutti letto del fulmineo successo nell'attacco all'Apple MacBook Air durante la gara PWN2OWN tenuta durante la conferenza CanSecWest. Per valutare in modo più equilibrato come emerge il confronto tra i diversi sistemi è bene che leggiate come si siano evolute le regole della gara: notate come l'articolo cerchi di far notizia con il fatto che Windows Vista sia stato il secondo a cadere, per poi leggere che ciò sia stato possibile grazie ad una vulnerabilità di Adobe Flash (!!). Avrei voluto capire se Linux fosse stato analogamente equipaggiato con gli stessi plug-in Adobe e, nel caso, quali aspetti del sistema operativo abbiano permesso di rimanere immune all'attacco che invece ha funzionato su Vista: peccato che questi dettagli tecnici nessuno riesca mai a darli... :-(... Anche l'articolo di Luca Annunziata su Punto Informatico fa emergere interessanti interrogativi su quali dinamiche partigiane possano nascondersi dietro queste gare...

Prima considerazione: come Roberto Scaccia, mi trovo a ribadire da un lato la sorte comune di TUTTO il software nel doversi evolvere per ridurre le vulnerabilità di sicurezza, dall'altro a segnalare l'importanza fondamentale dei processi di sviluppo di codice sicuro, quello che per Microsoft è l'SDL (ve lo ripeterò fino alla noia...). Nel caso in oggetto: Vista poteva essere super blindato, ma se Adobe Flash non lo era siamo punto e a capo...

Seconda notizia: il paper "0-Day Patch - Exposing Vendors (In)security Performance" di due ricercatori svizzeri esposto al BlackHat Europe 2008 ha evidenziato un confronto Microsoft-Apple che risulta impietoso per la credibilità degli aspetti di sicurezza di Apple (soprattutto alla luce dei proclami con cui Apple ha vantato tale superiorità...). Lascio il commento alle parole di Ollmann dell' ISS X-Force Team di IBM che scrive:

"In essence, with their “0-day Patch” metrics, they managed to show just how far Apple is trailing Microsoft in security patch responsiveness – in fact, after inspecting their graphs, Apple appears to be trending entirely in the wrong direction; more vulnerabilities, longer patching times, more 0-days, etc. – not the sort of thing we expect from a well known software vendor.".

Seconda considerazione: sempre Ollmann ipotizza il motivo di tale "wrong direction":

"Apple’s biggest problem appears to be that they treat every new vulnerability as a potential PR disaster rather than an opportunity to visibly reinforce their work in securing their customers."

Si può provare a muovere qualche critica alla gestione delle vulnerabilità da parte di Microsoft ma di sicuro non si può dire che lo sforzo sia mirato alla difesa dell'apparenza rispetto alla sostanza della difesa dei clienti e dell'affidabilità del business che essi realizzano con la nostra piattaforma.

E' per questo che non godo a leggere queste notizie: lo spirito è quello di chi vede che nessuno (Apple in questo caso) sia stato in grado di imparare la lezione dalla esperienza di Microsoft dei primi anni 2000 e sfruttare strategicamente questo vantaggio. Qual'è il triste risultato? Gli utenti sono costretti a vivere nuovamente il disagio di soluzioni (anche recenti!) che non sembrano aver contemplato la sicurezza in modo nativo, e che potrebbero essere oggetto di nuove minacce visto l'evidente aumento della diffusione di dispositivi Apple: è come se la strada verso la realizzazione del Trustworthy Computing si stesse riallungando... :-(

Share this post :

L'iniziativa SafeCode inizia a delinearsi: pubblicato il primo whitepaper

Feliciano Intini — Fri, 15 Feb 2008 10:53:03 GMT

Non so se ricordate quando vi ho segnalato l'avvio di SafeCode, a valle della scorsa RSA Europe Conference: apprendo ora da Michael Howard che è stato prodotto il primo whitepaper di questa iniziativa: "Software Assurance: An Overview of Current Industry Best Practices". La scorsa veloce di queste 20 paginette mostra la semplice collezione di best practice da parte delle prime società che hanno deciso di aderire: EMC, Symantec, Juniper Networks, SAP, Microsoft. Ok, vi sembrerà ancora un taglio molto marketing, ma fate caso al modo con cui le diverse aziende stanno portando il loro contributo: si sta davvero cercando di creare un modello di ampio respiro per indirizzare il tema della "Software Assurance", l'impegno da parte di aziende che realizzano software commerciale ad implementare dei processi strutturati per lo sviluppo di codice sicuro, con l'obiettivo di ridurre le vulnerabilità, migliorare la resistenza agli attacchi (che, ricordate, si evolvono costantemente), e proteggere l'integrità dei sistemi.

Michael segnala anche di essere stato nominato coordinatore del gruppo di lavoro dedicato al Development Process: per chi lo conosce, questa non può che essere una garanzia! (non a caso Michael è stato segnalato tra le 15 figure più influenti sulla sicurezza: probabilmente in questa lista manca qualcuno di importante, e qualcuno è di troppo...;-)..., ma la sua presenza è più che meritata!).

Una domanda per voi, che può sembrare una provocazione ma, davvero, è solo uno spunto di confronto e di discussione aperta: credete che il modello di sviluppo del codice Open Source abbia, oggi, dei processi analoghi, in termini di efficienza ed efficacia, per assicurare nelle mani degli utenti un codice sorgente che sia della migliore qualità possibile dal punto di vista della sicurezza?

Share this post :

Ancora numeri che parlano da soli: Internet Explorer a confronto con Firefox

Feliciano Intini — Sat, 01 Dec 2007 17:50:47 GMT

Chi mi legge da tempo probabilmente alla vista del titolo avrà avuto un deja-vu, e si sarà ricordato dello scorso post di confronto di vulnerabilità tra Windows Vista e i sistemi operativi precedenti e concorrenti. Lo stesso collega Jeff Jones che aveva realizzato quell'analisi, ha appena terminato un nuovo interessante confronto tra Internet Explorer e Firefox. Perché solo tra questi due browser? Per semplici motivi di diffusione: sono i due browser di fatto più presenti. La dozzina di pagine del report si leggono molto velocemente, e meritano di essere lette tutte: io vi riporto solo poche considerazioni di sintesi.

Primo punto: di solito, come atteggiamento personale, prima di guardare ai difetti degli altri preferisco cercare di risolvere i miei, quindi vi ripropongo la tabella che mostra come è migliorata la situazione tra le diverse versioni di IE: IE7 ha appena compiuto un anno di vita (leggete il post del team di IE7 a riguardo) e quindi è possibile metterlo a confronto con IE6

Il trend di riduzione c'è indubbiamente, ma si può ancora migliorare.

Secondo punto: se guardo alla tabella di confronto tra IE e Firefox che vi riporto sotto e rileggo l'articolo in cui Mozilla dichiarava di essere un browser più sicuro di IE mi viene da dire che il principio evangelico usato al punto precedente (di togliere la trave dal proprio occhio prima di affannarsi a togliere la pagliuzza dall'occhio degli altri ...) sarebbe meglio che fosse adottato anche da Mozilla... ;-)

Terzo punto: l'analisi ha dato modo di confrontare anche i due diversi modelli di supporto del ciclo di vita di prodotto. Firefox ha lifecycle molto più brevi di IE e questo ha una importante implicazione di sicurezza: la probabilità che ci siano in circolazione versioni non più supportate (e quindi prive delle ultime patch di sicurezza) è molto più elevata.

Detto questo, sono il primo a dire che non mi sentirei di avere un atteggiamento trionfalistico: sulla base della mia esperienza devo dire che dobbiamo proprio ad Internet Explorer molta della pessima reputazione che Microsoft ancora ha rispetto alla sicurezza. Dall'altra parte vi rammento che IE è il prodotto più delicato in termini di compatibilità applicativa e quindi il più difficile da migliorare: stravolgere le funzionalità di IE significa bloccare un numero impressionante di applicazioni web.

Questo non deve naturalmente frenare il processo di evoluzione: i numeri esposti in questo report credo dimostrino ancora una volta che l'SDL (IE7 è il primo ad averlo completato tutto) stia producendo i suoi frutti.

Importanti conferme dal report SANS Top-20 2007 sull'evoluzione dei Security Risks

Feliciano Intini — Fri, 30 Nov 2007 16:18:48 GMT

Il report SANS Top-20 è storicamente una delle più importanti risorse nelle mani del professionista di sicurezza per apprendere l'evoluzione delle minacce dirette ai sistemi informatici. Deve il suo nome "Top-20" al fatto che quando è stato stilato nella sua seconda versione (nel 2001) comprendeva la lista delle 20 vulnerabilità considerate più critiche (la prima versione del 2000 aveva una lista di solo 10 vulnerabilità). Negli anni poi il report ha evoluto la sua struttura, con la suddivisione delle vulnerabilità più critiche (che nel tempo sono aumentate) in una serie di categorie: Client-side Vulnerabilities, Server-side Vulnerabilities, Security Policy & Personnel, Application Abuse, Network Devices, Zero Day Attacks.

Nella versione del report appena pubblicato per il 2007, "SANS Top-20 2007 Security Risks", la sintesi dell'analisi è molto chiara e desidero riportarvela nella versione originale (estratta dal relativo Executive Summary):

"The cyber arms race continues. Cyber criminals and cyber spies have shifted their focus again, successfully evading the countermeasures that most companies and government agencies have worked for years to put into place. Facing real improvements in system and network security, the attackers now have two new prime targets that allow them to evade firewalls, antivirus, and even intrusion prevention tools: users who are easily misled and custom-built applications. This is a major shift from prior years when attackers limited most of their targets to flaws in commonly used software"

In questa sintesi e nel report di dettaglio ci sono molte conferme alle diverse considerazioni che ho già avuto modo di condividere, sia quando ho parlato dei principi di Security Governance, che del recente Microsoft Security Intelligence Report v3:

I reali miglioramenti dei sistemi operativi ("Operating systems have fewer vulnerabilities that can lead to massive Internet worms")e della sicurezza di rete, che portano chi attacca a cercare nuovi punti deboli, ora identificati nella:

poca robustezza della sicurezza applicativa del software realizzato in casa, e l'urgenza di un processo come il SDL: "Until colleges that teach programmers and companies that employ programmers ensure that developers learn secure coding, and until those employers ensure that they work in an effective secure development life cycle, we will continue to see major vulnerabilities in nearly half of all Web applications."
Debolezza degli utenti nei confronti degli attacchi di social engineering, anche in virtù dell' aumento di attacchi verso il client: "Today it is equally important, perhaps even more important, to prevent users having their computers compromised via malicious web pages or other client-targeting attacks"

Necessità di continuare a fare attività di hardening: "The default configurations for many operating systems and services continue to be weak and continue to include default passwords"
L'urgente attenzione verso la Data Protection: "it is now critical to check the nature of any data leaving an organization's boundary"

Gli altri spunti del report sono davvero tanti, e possono aiutare concretamente nell'analisi di rischio che ogni azienda dovrebbe realizzare in modo costante, quindi buona lettura!

Microsoft partecipa alla nuova SAFECode alliance

Feliciano Intini — Wed, 24 Oct 2007 16:14:14 GMT

Prima che mi dimentichi desideravo segnalarvi al volo un'altra notizia interessante emersa all'RSA Europe Conference: è nata una nuova iniziativa di collaborazione industriale di tipo non-profit, Software Assurance Forum for Excellence in Code (SAFECode), avviata da EMC, Juniper Networks, Microsoft, SAP, e Symantec. La missione di questo forum è aumentare la comprensione (sia internamente all'industria IT, che esternamente) delle best practices relative al progetto, realizzazione e distribuzione di applicazioni, servizi ed hardware che abbiano il software come comune denominatore. Interessante anche l'impegno nel migliorare i percorsi formativi per gli sviluppatori , in particolar modo sul tema sicurezza. Come potete intuire la presenza di Microsoft è giustificata dal forte interesse a condividere con gli altri vendor il proprio processo di Security Development Lifecycle (SDL): nonostante l'SDL stia ampiamente dimostrando di essere uno dei migliori modelli sul mercato, può e ovviamente deve essere ulteriormente migliorato tramite la collaborazione con le altre aziende leader nello sviluppo del software.

Hackers o Crackers ? In Microsoft solo “%41%43%45%20%54%65%61%6d”

Feliciano Intini — Tue, 09 Oct 2007 09:18:44 GMT

Alla fine di agosto è nato un blog di Microsoft mooolto interessante per i veri appassionati di sicurezza (come me e voi), dal nome suggestivo: "Hackers @ Microsoft". L'ovvio intento è quello di condividere le esperienze più interessanti del team che supporta il processo del Security Development Lifecycle con le tecniche di penetration testing e security code review. Dopo il post di benvenuto il blog è andato in stand-by. Fortunatamente è riemerso in questi giorni, con una curiosa novità: il nome (non l'indirizzo, che rimane http://blogs.msdn.com/hackers) è cambiato, diventando un impronunciabile "%41%43%45%20%54%65%61%6d" (che dovrebbe essere la codifica di "ACE Team", il gruppo di Application Consulting & Engineering che si occupa di sicurezza applicativa, performance e privacy, dotato anche di blog). Motivo di tale modifica è il desiderio di (traduco liberamente) "attenuare le perplessità della media dei lettori che potrebbero non comprendere bene la differenza tra i gli ethical hackers e i cattivi, e inavvertitamente associare Microsoft alla connotazione negativa di tale termine...". Vi vedo che state sorridendo sotto i baffi, e vi capisco ... ma vi chiedo di essere indulgenti: questo atteggiamento che sembra una sorta di censura è in realtà solo il frutto della cultura anglosassone che ha un'attenzione spasmodica per le pubbliche relazioni. L'uomo anglosassone non riesce a vivere gli imprevisti, ha bisogno di essere sempre preparato a priori rispetto a quello che deve affrontare in pubblico, perché teme di non saper gestire al volo le situazioni.

Anche se sono convinto che il nome delle cose ricopre una parte fondamentale per la definizione delle stesse, rispetto al blog "Hackers @ Microsoft" sinceramente non credo che ci fosse bisogno di prendere le distanze dalla connotazione negativa del termine hacker, perché ritengo sia ovvio il contesto positivo nel quale lo si usa... ma, come detto, gli anglossassoni sono paranoici su queste cose. Personalmente non riesco facilmente a usare i due termini per distinguere i ricercatori di sicurezza buoni (hackers) da quelli cattivi (crackers), forse anche per l'assonanza del secondo termine con gli snack salati... Io preferisco separare l'atteggiamento tecnico dall'intenzione con cui si operano certe azioni, e vedo nell'hacker la passione di non fermarsi di fronte all'evidenza e di andare oltre, cercando di conoscere a fondo un sistema, meglio di chiunque altro. Questo atteggiamento permette sì di individuare meccanismi per aggirare le limitazioni che un sistema di sicurezza intende imporre, ma il decidere di sfruttare questa conoscenza per danneggiare gli altri è un altra storia e va chiamato con il suo vero nome: è un crimine. Voi cosa ne pensate ?

In ogni caso, nome impronunciabile a parte, non mancate di aggiungere questo blog ai vostri feed, e non perdete di leggere il post dal titolo "The difference between pentesting and an application development security process Part I", dove si ribadisce l'importanza dell'adozione di un processo di sviluppo di codice sicuro (per indirizzare le "root cause" delle vulnerabilità e non solo gli effetti come fa il pentest), e la considerazione (che condivido appieno) di una sostanziale convergenza tra industry diverse nei confronti dell'approccio alla sicurezza: che siate un cliente bancario, manifatturiero o telecom, l'obiettivo è sempre quello di proteggere adeguatamente i dati dei clienti (ricordate la 16a perla di Security Governance ?).

Brevi conferme ad alcune perle di security governance

Feliciano Intini — Mon, 30 Jul 2007 16:16:14 GMT

Non lo faccio (solo) per farmi bello ... ;-), ma in questi giorni ho letto qualche articolo che conferma alcune delle considerazioni fatte nelle mie famose "17 perle di security governance", e ho pensato di condividerli per consolidare l'importanza di queste best practice:

Perla N° 15: necessità e urgenza dei processi di secure code development
Study: Largest vendors account for fewer software flaws
In sintesi: The top 10 most vulnerable software vendors, including Microsoft, are contributing a smaller percentage of all vulnerability disclosures per year compared to five years ago, an IBM analysis says.
E tra le diverse considerazioni: "...the most vulnerable vendors typically have also been the biggest software vendors and those with the largest installed bases. Traditionally, security researchers and hackers have gone after vendors with the biggest installed bases because that is where they can have the biggest impact. As larger vendors begin to do a better job of locking down their software, hackers and software researchers have begun focusing their attention on newer vendors and their applications ..."

Perla N° 4: la sicurezza nei rapporti con partner che accedono alla nostra rete
Third Parties Fumble Data Handoffs
In sintesi: Companies are learning -- the hard way -- that the security chain is only as good as its weakest link. In the past few days, two major organizations have suffered breaches of their constituents' personal data -- not because of something they did, but because of something their partners did.

Perla N° 2: necessità ed efficacia delle Security Policy
Firms urged to educate staff on ICT policies
In sintesi: Over three-quarters of employers do not take steps to make sure their staff understand the ICT policies they have in place, according to new research.

Come promesso ho anche aggiornato il mini-portale con i link a questi articoli.

Sei sicuro della sicurezza del TUO codice ?

Feliciano Intini — Thu, 28 Jun 2007 10:22:00 GMT

Delle "17 perle" di cui vi ho appena detto, quella che ha suscitato maggiori domande di approfondimento nei 3 eventi in cui ho avuto modo di parlarne è stata appunto la 15a: Sei sicuro della sicurezza del TUO codice ? Il concetto di fondo che ho espresso riguardo a questo punto è esattamente quanto avevo già indicato al termine del mio post precedente, che vi riporto: con l'irrobustimento della piattaforma di base, chi attacca tenderà nel tempo a spostare la sua attenzione verso gli strati più alti a livello applicativo, sul codice custom, quello scritto dalle terzi parti o dal cliente stesso, dove sarà più facile ritrovare bug di sicurezza da sfruttare per un attacco, più mirato ma non meno pericoloso...(read more)

I primi 6 mesi di Windows Vista: quando i numeri parlano da soli

Feliciano Intini — Thu, 21 Jun 2007 17:24:00 GMT

Se avete letto il mio precedente post, quando il mio collega Jeff Jones ha pubblicato il report simile sui primi 90 giorni di Windows Vista, sapete già come la penso sulle statistiche di confronto delle vulnerabilità tra i diversi sistemi operativi. Ma i risultati che emergono da questo nuovo report, stilato a 6 mesi esatti dalla disponibilità di Windows Vista, meritano la giusta attenzione. Come potete notare dalla prima delle quattro tabelle presenti nel report i numeri parlano davvero da soli: ...(read more)

MOICE: la sicurezza di Open XML offre una protezione retroattiva per Office pre-2007

Feliciano Intini — Tue, 15 May 2007 00:18:00 GMT

Un post da non perdere è quello in cui David LeBlanc spiega il tool di prossima pubblicazione MOICE, "Microsoft Office Isolated Conversion Environment". Lasciandovi il piacere di leggerlo per intero, richiamo in questa sede alcuni spunti interessanti che confermano diversi elementi di strategia di sicurezza già accennati nel mio blog. Cosa è MOICE ? ...(read more)