Spesso si parla di metodologie di gestione del ciclo di vita del software “di moda” (Scrum, etc.) tralasciandone altre che, seppur meno famose, hanno una rilevanza non indifferente.

Una di queste è SDL, Security Development Lifecycle. Può suonare abbastanza poco conosciuta ai più, ma abbiamo diversi esempi “sottomano”.

A partire da Windows Server 2003 infatti, i sistemi operativi in Microsoft sono sviluppati secondo il paradigma SDL. O anche l’intera piattaforma Windows Live, per citare un altro esempio. Per non parlare di Internet Explorer, Silverlight, ecc.

Ma come funziona, questa metodologia?

Si basa su sette fasi fondamentali, che vedremo nel dettaglio nei prossimi post (training escluso). Sono:

La security è messa al centro di tutto. Ogni fase comprende una verifica continua della sicurezza di ogni singolo livello applicativo.

L’Optimization Model prevede quattro livelli:

All’inizio dell’adozione di SDL si parte da Basic. La security è reattiva, ossia si reagisce solo dopo aver scoperto una falla. Ma non sappiamo quante falle possiamo avere in un sistema, potenzialmente sono infinite. Quindi il rischio per il cliente è indefinito.

“Perchè SDL?” domanda che ci si può porre senza problemi. La risposta è molto variegata. Può nascere da una necessità (Windows Live ne è un esempio lampante: ci viaggiano i miei dati la sopra!) o da una volontà (Verisign ad esempio potrebbe sviluppare con qualunque SDLC preferisce, ma ha scelto SDL in quanto è il più adatto al business aziendale), ma comunque è una metodologia che deve avere delle basi di adozione importanti, visto che non è la più immediata da mettere in atto.

Alla voce “costi”, una delle spese maggiori è rappresentata dal training, la prima fase di SDL. Prima di cominciare con la raccolta di requisiti ed il design si deve essere ben preparati alle problematiche che si affronteranno, mediante corsi e formazione specifici per entrare in profondità negli argomenti.

Si va dal Threat Modeling (che vedremo a seguito) fino agli scenari di attacco, passando per le varie librerie utilizzabili per mitigare questi attacchi fino alla preparazione per utilizzare i tools di analisi e verifica.

Questo tipo di formazione è fondamentale, e molto apprezzata. Alcuni sviluppatori del team di Windows Live hanno commentato, dopo la prima ondata di training:

“This was one of the best courses I’ve attended in Microsoft. It was very relevant to my product and feature.”

“The hands-on, in-class practice was very useful. I can directly apply these techniques.”

“The course was very informative and I really liked the in-depth coverage of the Windows Live–specific libraries and APIs that I need to use.”

I corsi devono essere estremamente customizzati in base al livello ed alle esigenze del team, e soprattutto effettuati in tempi strategici ai fini della pianificazione.

Da un training fatto bene, si ottiene un egregio risultato. Se il training non viene eseguito o viene considerato come secondario, lasciate perdere SDL.

Nel prossimo post vedremo la fase di raccolta dei requisiti. Per commenti/opinioni/improperi vari, sono qui .