L'approccio di Microsoft alla sicurezza nello sviluppo del software

di Feliciano Intini (Chief Security Advisor, Microsoft Italia) - Nel dibattito sullo studio Fortify sulla sicurezza del software e l'open source interviene anche Microsoft Italia, in un commento ospitato su Punto Informatico

Roma – La lettura del commento di Alessandro Bottoni al recente studio pubblicato da Fortify ( Open Source Security Study ) mi ha dato la possibilità di fare un incredibile salto indietro nel tempo, e di rivivere, non senza un pizzico di nostalgia, un periodo cruciale per l’evoluzione dell’approccio di Microsoft nei confronti del tema sicurezza. Certo, non stiamo parlando di decenni, ma si sa, nel mondo dell’informatica sei anni sono quasi un’eternità. È proprio del gennaio 2002 l’avvio dell’iniziativa Trustworthy Computing (TwC) : l’esperienza maturata nella gestione delle infezioni di malware già citate (Code Red – Agosto 2001, Nimda – Settembre 2001) fa maturare in Microsoft un cambio di rotta, netto e deciso, nella gestione dello sviluppo del proprio software. Si riconosce la necessità e l’urgenza di far diventare la Sicurezza e la Privacy elementi imprescindibili all’interno di tutto il ciclo di sviluppo del software, in un periodo storico in cui questi temi erano di fatto seriamente considerati solo da pochi e circoscritti ambiti (militare, governativo, bancario): da questa rielaborazione di esperienze interne e di adozione delle migliori security best practice nasce il Microsoft Security Development Lifecycle (SDL) , un profondo rinnovamento della modalità con cui Microsoft concepisce, progetta, sviluppa e verifica la qualità dei propri prodotti e servizi, un processo ampiamente documentato in modo da essere liberamente adottabile e riutilizzabile da chiunque intenda ottimizzare lo sviluppo di codice dal punto di vista degli aspetti di sicurezza.

L’effetto sui propri processi interni fu dirompente: per l’intero febbraio 2002 la produzione di tutte le linee software venne interrotta per permettere a circa 8000 programmatori di seguire obbligatoriamente un aggiornamento della propria formazione tecnica sulle più recenti modalità di attacco e sulle best practice di scrittura di codice sicuro, il cosiddetto “Microsoft Security Push” .

La storia di questi anni ha già avuto modo di confermare la validità di quella svolta e dell’impegno investito su questo tema, sia dal punto di vista quantitativo che qualitativo. Le statistiche che mostrano una evidente riduzione delle vulnerabilità, sia nel confronto interno di versione in versione che nel confronto competitivo, sono davvero significative. L’apprezzamento del mercato per la validità e l’efficacia del processo SDL è diventato unanime:
“… we actually consider Microsoft to be leading the software (industry) now in improvements in their security development life cycle…” – John Pescatore, Gartner, Inc. “Is Windows Safer?” CRN, February 10, 2006
“Microsoft’s Trustworthy Computing initiative is perhaps the most advanced and comprehensive application security program in the industry.” – Chenxi Wang, Forrester Research, Inc. “Managing Application Security From Beginning To End”, August 14, 2007

Tenendo in debito conto l’attuale scenario di rischio che vede una chiara prevalenza di attacchi diretti al livello applicativo (Gartner riporta che è tale il 75% degli attacchi) è sinceramente ineludibile la necessità di rivedere e aggiornare le proprie modalità di sviluppo del software. Non è forse questo il senso della ricerca Fortify? Essa di fatto ribadisce l’importanza di affrontare il tema della sicurezza nel suo approccio olistico (persone, processi e tecnologie) e in particolare di non trascurare l’accesso alla Security Expertise , l’adozione di un Secure Development Process , e l’uso di strumenti per l’identificazione di vulnerabilità: sono aspetti da cui qualcuno può sentirsi esentato?

Sarebbe quindi auspicabile riconoscere la validità delle considerazioni conclusive che appaiono essere il giusto pungolo a non dare per scontato che ci siano davvero software intrinsecamente sicuri: nessun sistema è invulnerabile, e il mancato utilizzo delle security best practice di cui detto aumenta esponenzialmente nel tempo il rischio di essere facilmente oggetto di attacchi in grado di andare a buon fine ed arrecare un danno serio.

D’altra parte le stesse comunità Open Source sono già impegnate in tal senso (OWASP ne è un esempio) e riconoscono l’opportunità e l’urgenza di tale approccio: la recente iniziativa oCERT non è forse conferma di uno dei punti di debolezza indirizzati da Fortify? Perché quindi non abbandonare il confronto/scontro fine a se stesso e non dedicare le proprie energie ad attivare alleanze strategiche su questi temi ( SafeCode è un esempio in ambito software commerciale)? L’esempio del fronte comune si è dimostrato possibile proprio in questi giorni: non è degno di nota lo sforzo che ha accomunato progetti Open Source e diversi vendor di software commerciale nello sviluppo della patch per correggere la recente vulnerabilità DNS ?

L’avanzamento della sicurezza delle realtà IT e di Internet passa necessariamente dall’impegno di tutti i fornitori nel costante miglioramento delle proprie soluzioni, dall’incremento di confronto e collaborazione reciproca (vedi iniziativa ” End to End Trust “), e dall’interoperabilità delle diverse piattaforme eterogenee. Quale migliore contributo a favore di tali processi di innovazione collaborativa del rinnovato impegno di Microsoft in ambito Interoperabilità ? Questa è la Microsoft di oggi, una fabbrica di software e servizi impegnata a 360 gradi nella tenace ambizione di realizzare, proprio grazie ad essi, il pieno potenziale delle persone.

Mi auguro che queste mie considerazioni possano facilitare una nuova modalità di confronto competitivo, più costruttiva e più efficace nel contribuire ai progressi nel campo della sicurezza IT che tutti ci aspettiamo.

Feliciano Intini
Chief Security Advisor, Microsoft Italia

La tua email sarà utilizzata per comunicarti se qualcuno risponde al tuo commento e non sarà pubblicato. Dichiari di avere preso visione e di accettare quanto previsto dalla informativa privacy

  • Maurizio Firmani scrive:
    La vera novità sono i profili RAW
    Finora Lightroom e Camera Raw (il plugin di Photoshop) avevano dei grossi limiti sulla resa dei colori delle immagini importate dai file raw. Con la profilazione delle singole fotocamere (ancora in beta presso gli Adobe Labs http://labs.adobe.com/wiki/index.php/DNG_Profiles) ora Lightroom e ACR possono ottenere gli stessi risultati dei convertitori dedicati. Ho provato giusto ieri sera l'uso dei profili Nikon per ACR, e devo dire che i risultati sono notevolmente migliori rispetto al passato. La profilazione purtroppo funziona solo per ACR 4.5 e Lightroom 2.0, però.
    • Giovanni L scrive:
      Re: La vera novità sono i profili RAW
      - Scritto da: Maurizio Firmani
      Finora Lightroom e Camera Raw (il plugin di
      Photoshop) avevano dei grossi limiti sulla resa
      dei colori delle immagini importate dai file raw.
      Con la profilazione delle singole fotocamere
      (ancora in beta presso gli Adobe Labs
      http://labs.adobe.com/wiki/index.php/DNG_Profiles)Puoi spiegare un pochino che sono (non come si installano o come si usano in lightroom), magari puntando a un wiki o una guida?
Chiudi i commenti