Security Development Lifecycle: Design and Threat Modeling

La fase successiva a Training e raccolta dei requisiti è quella del Design, dove si inizia a modellare la nostra applicazione. In questa fase si utilizza il Threat Modeling, ossia un processo ripetibile per identificare e mitigare preventivamente i possibili attacchi che potrebbero essere sferrati contro il nostro software.

Prima di cominciare a modellare effettivamente, si deve però avere ben chiaro l’impatto che le varie funzionalità possono avere oltre che sulla security “tecnica”, anche su un altro argomento molto delicato: le conseguenze legate alla privacy dell’utente.

In SDL si tiene conto del documento che Microsoft ha stilato chiamato “Privacy Guidelines for Developing Software Products and Services”, che prevede una serie di indicazioni e scenari ben precisi atti ad aiutare il design dell’applicazione. Tutto ruota intorno al seguente principio fondamentale:

“Customers will be empowered to control the collection, use, and distribution of their personal information. ”

Per eseguire invece la modellazione ci si avvale di un tool chiamato SDL Threat Modeling Tool. Questo è uno strumento che si integra in Visio, e che permette ai Software Architect di identificare e mitigare potenziali minacce in uno stato embrionale della soluzione software, quando il costo di correzione è basso e la soluzione è più semplice da implementare rispetto ad uno stato avanzato di sviluppo.

Non è l’obiettivo di questo post quello di andare in profondità su TMT, ma c’è un fantastico articolo su MSDN Magazine a riguardo.

Il Threat Modeling in SDL (ne esistono varie declinazioni) si appoggia ad un modello chiamato STRIDE, acronimo di Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, ed Elevation of Privilege. Questo acronimo indica la classificazione delle possibili minacce attuabili contro un sistema.

Esistono quattro componenti fondamentali nel Threat Modeling:

• External Entities
• Processes
• Data Stores
• Data Flows

Ognuna di queste componenti ha alcune minacce di STRIDE applicate, ed altre vengono invece scartate. Ad esempio un mail server (Exchange Server) avrà una componente critica classificata sotto Information Disclosure, mentre Windows Audio non dovrà preoccuparsene.

Next one, Implementation step

Il ruolo fondamentale in SDL è quello del Security Advisor. Il suo ruolo è quello di fare da mediatore fra il team di sviluppo e “la sicurezza”. Sicurezza che in Microsoft è rappresentata da un team centrale dedicato, ma potrebbe essere anche il dipartimento sistemi informativi della nostra azienda.

Il SA assiste il team di sviluppo in ogni fase del ciclo di vita, garantendo la corretta adozione delle policy e delle best practice. Inoltre dialoga direttamente con il management, onde evitare spiacevoli sorprese al momento del rilascio.

SDL è flessibile. Nasce adottando lo Spiral Model, ma è possibile applicare SDL come metodologia di gestione del ciclo di vita del software processo a qualunque metodologia di sviluppo. Posso usare MSF-Agile+SDL, Scrum+SDL, ecc…

Quindi la raccolta di requisiti non è una fase “tightening”, stringente, ma può essere modellata sulle necessità del DevTeam in base alla metodologia di sviluppo utilizzata.

La raccolta di requisiti parte da una analisi profonda delle problematiche di sicurezza. Il Security Risk Assessment (un questionario in cui si valutano le feature una ad una) è un passo fondamentale che aiuta il Program Manager a valutare il livello di rischio delle singole funzionalità.

In questa fase si deve capire come integrare la sicurezza all’interno del processo di sviluppo, identificare gli obiettivi chiave e cercare di massimizzare la sicurezza minimizzando modifiche bloccanti ed invasive al piano d’azione. I piani possono cambiare, ma i requisiti devono avere il giusto peso, ne sottovalutati ne sopravvalutati.

Nel prossimo post vedremo la fase di design .

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 .