Riflessioni a metà strada tra VSTS, TFS e SDL

dove:
VSTS sta per Visual Studio Team System
TFS sta per Team Foundation Server
SDL sta per Security Development Lifecycle

Sto (quasi) finendo di leggere The Security Development Lifecycle, di Micheal Howard e Steve Lipner. Il giorno in cui lo acquistai, mi chiesi se faceva al caso mio. Qualcuno di UGI – via Messenger – mi fece la stessa domanda. Quel giorno lo acquistai perchè andai ad un evento Microsoft Technet, la sicurezza la faceva da padrone e Francesca Di Massimo durante la sua sessione mise particolare enfasi sull’argomento SDL, per cui mi sono fatto convincere ad acquistare il libro dal banchetto di Gorilla.it.

Stasera ho raggiunto poco più della metà del libro, c’è ancora molto da leggere, ma un’idea me la sono fatta. Conoscendo Sua Maestà Raffaele di persona, sapevo già che la sicurezza è un argomento che bisogna affrontare sempre, ma il libro mi ha ficcato bene in testa molte spiegazioni. Innanzitutto, ficchiamoci bene in testa una cosa molto semplice: la sicurezza riguarda ogni tipo di software, dal Blocco Note a Microsoft Money. E non è una battuta. Se Blocco Note soffrisse di una qualche vulnerabilità, ne risentirebbe l’intero sistema, perchp basterebbe sfruttare quella falla per scatenare un DoS sul sistema. La sicurezza riguarda l’affidabilità, e per diretta conseguenza la qualità di un sistema software, riguarda la protezione dei dati, la garanzia che i dati vengano trattati rispettando la privacy, etc. etc.

SDL è un insieme di procedure/processi/best practices che consentono di progettare e disegnare software avendo come obiettivo ultimo la sicurezza. I punti previsti da SDL sono davvero tanti e complessi e sicuramente sono la persona meno adatta a spiegarveli uno per uno. SDL riguarda l’analisi dei requisiti, evidenzia porzioni di codice a diversi livelli di rischio, permette di capire quali features abilitare di default oppure no durante il setup dell’applicazione, prevede la creazione di documentazione aggiornata al codice per evidenziare possibili punti critici dell’applicazione, detta le basi per testare l’applicazione stessa usando logiche di Fuzz Testing, Penetration Testing e Unit-Testing, etc. etc. A…dimenticavo…eccetera, eccetera, eccetera. C’è molto davvero.

Si parla anche di come organizzare il team affinchè sia possibile aderire il più possibile ai processi previsti dalla SDL. Ingegneri, architetti, developer, esperti di security, altri tecnici: tutti devono collaborare, rispetto i ruoli dei lead, e dialogare assieme per raggiungere gli obiettivi. Questo significa poter accedere alla stessa documentazione (aggiornata), poter accedere tutti assieme ai bugs rilevati per poter determinare dove si trova la nostra “bug bar”, poter verificare in ogni momento a che punto siamo con lo stato d’avanzamento del progetto e così via. Riporto una frase tratta dal libro:

Constant communication to the software development team about the progress of the security push is absolutely critical to the push process. Communication colud include the following: regular e-mail messages, an intranet site with live statistics.

Il testo va avanti, dicendo che nelle comunicazioni dovrebbero includere: numero di bug trovati, numero di nuovi bug rilevati nelle ultime 24 ore, numero di files contenuti nel progetto, test eseguiti con l’esito sotto forma di grafico, il nome dei bug-hunter più bravi, e così via. Devo proprio dirlo che mi sembra la descrizione della combinazione VSTS+TFS?

TFS gestisce ogni Team Project con un portale dedicato basato su Sharepoint (collaborare e dialogare), attraverso il quale l’intero team può avere accesso a tutte la documentazione necessaria allo sviluppo. Non solo: possiamo accedere a statistiche costantemente aggiornate su quanti WorkItems mancano alla fine del lavoro, quanti bug sono stati corretti, quanti test sono stati eseguiti e con quale esito, quanto codice è stato committato oggi e via dicendo. TFS permette di tracciare i bugs rilevati con i WorkItem. Ancora una volta, è chiaro come il tandem VSTS+TFS non sia solo un semplice tandem di software, ma sono due strumenti che fanno parte di uno scenario più ampio, che si incastrano perfettamente in uno scenario molto più vasto. In questo caso, la piena predisposizione all’aderenza alla SDL.

Uno dei processi finali della SDL è la FSR, che sta per Final Release Review, una sorta di esame finale della nostra applicazione, per vedere se è stata sviluppata con tutti i criteri previsti dalla SDL. Questo significa un miliardo di cose: documentazione sulla superficie di attacco, documentazione sul threat model, documentazione sui protocolli di rete, situazione di ciascun bug, documentazione sulla risk analysis. Sarebbe uno sbaglio terrificante mettersi a scrivere tutto alla fine, e questo è ovvio. L’utilizzo di una piattaforma basata su TFS semplifica significativamente tutti i processi previsti dalla SDL: semplifica la gestione, il mantenimento e l’accessibilità delle informazioni e di conseguenza il nostro lavoro. Lavoro di chiunque, dal capo-progetto al più piccolo dei developer.

Technorati Tags: programming security TFS