Programmazione.it v6.4
Ciao, per farti riconoscere devi fare il login. Non ti sei ancora iscritto? Che aspetti, registrati adesso!
Info Pubblicità Collabora Autori Sottoscrizioni Preferiti Bozze Scheda personale Privacy Archivio Libri Corsi per principianti Forum
The Security Development Lifecycle
Recensito da Paolo De Nictolis il 17-04-2007 ore 11:48
Copertina ISBN: 0735622140
Autori: Michael Howard, Steve Lipner
Editore: Microsoft Press
Lingua: Inglese
Anno: 2006
Pagine: 322 + XXII
Allegati: CD-ROM con videocorso, documentazione di esempio sull’SDL ed un tool di testing
A marzo del 2007, Symantec ha riconosciuto a Windows il primato nella risoluzione delle vulnerabilità rispetto ad ogni altro sistema operativo; un primato che fa seguito ad altri significativi riconoscimenti tributati da Channel News, Enterprise Strategy Group ed eWEEK.com fra gli altri, e che stride pesantemente con la fama di sistema operativo poco sicuro, anche se già nel 2004 una ricerca della Forrester metteva in dubbio tale slogan. Va ugualmente contro il senso comune inculcato in questi anni scoprire che i ricercatori di Secunia hanno elencato un numero enormemente maggiore di vulnerabilità per Apache su Linux che per IIS su Windows. Un simile risultato è frutto dell'impegno profuso nella creazione di sistemi sicuri, sintetizzato in una metodologia di sviluppo, il Security Development Lifecycle (SDL), soggetta a revisioni semestrali ed alla quale contribuisce una vasta rete di esperti esterni al gigante di Redmond.

Il maggiore esperto di Sicurezza della Microsoft, quel Michael Howard già coautore del testo Writing Secure Code (del quale è uscito in questi giorni l'aggiornamento alle numerose novità rilasciate con Windows Vista), e Steve Lipner, il direttore della Security Engineering Strategy, ce ne illustrano in questo testo i principi e le 13 fasi, oltre che la sua applicazione nel contesto dello sviluppo agile, accompagnandoli con un CD di materiale formativo, tool e documenti di lavoro per il risk assessment. Onde evitare incauti acquisti, è bene precisare che il testo non è focalizzato, a differenza di Writing Secure Code, sul codice, ma è pensato per manager da un lato, architetti e progettisti dall'altro. SDL si concentra, da un lato nella riduzione del numero di vulnerabilità e minacce in tema di privacy, dall'altro in quella dei danni perpetrabili dalle vulnerabilità che, inevitabilmente, rimangono. Il testo si divide in tre parti: nella prima viene presentata la necessità storica e le caratteristiche di alto livello di SDL; nella seconda ne vengono descritte le 13 fasi; nella terza si presenta il materiale di riferimento su questa metodologia, a partire dal capitolo su come incorporare il processo SDL nei metodi di sviluppo agile, un lavoro unico ai tempi dell'uscita del libro.

Il primo capitolo ha carattere introduttivo sulle necessità di uno sviluppo che tenga conto degli aspetti di sicurezza, ed oltre a citare molti risultati numerici, illustra le relazioni fra tre dei quattro pilastri del Trustworthy Computing, ovvero sicurezza, privacy ed affidabilità (il quarto, le pratiche di business, viene affrontato nei successivi capitoli). Come alla fine di ogni capitolo, troviamo i riferimenti bibliografici e sitografici citati nello stesso. Il secondo capitolo ha un titolo tanto triste, quanto dolorosamente vero: i metodi di sviluppo del software correnti falliscono nella produzione di software sicuro. L'abusato concetto del Given enough eyeballs, all bugs are shallow è sbagliato su parecchi fronti perché assume che le persone siano motivate nell'effettuare review del codice; che le persone che le effettuano sappiano individuare un bug di sicurezza; e che ci sia una massa critica di revisori informati e motivate.

Nella realtà, è prassi comune che l'attività di review sia una delle più neglette dagli sviluppatori; è un dato di fatto che un genio come Crispin Cowan, uno sviluppatore di tecnologie open source, ma non certo un fanatico, non ha difficoltà ad ammettere che talvolta la promessa dell'open source è quella di mettere in grado molti occhi di rivedere il codice, ma nella realtà, questo non avviene. Avere un gruppo, anche numeroso, di entusiasti non vuol dire che questi siano in grado di scoprire bug di sicurezza; si tratta di un'attività che richiede un lungo training anche a sviluppatori esperti. Nel calcolo occorre tenere conto, non banalmente del numero di curiosi che possono scaricare – e magari mai installare – un software, quanto del tempo dedicato da ognuno di essi alle prove sul software stesso e, soprattutto, alle review del codice sorgente: una prassi non certo comune, al di là della possibilità offerta.

Fatto salvo tutto ciò, se anche il modello di sviluppo open source assicurasse la disponibilità di un numero sufficientemente elevato di revisori con sufficiente esperienza, la pretesa di una maggiore sicurezza del software open source in virtù della disponibilità del codice sorgente su cui effettuare review è sbagliata in partenza: lo scopo di un processo di sviluppo del software che tenga conto degli aspetti di sicurezza è un approccio proattivo, che consente di prevenire l'inserimento di bug nel codice, non certo il fare affidamento su una maggiore o minore capacità di scoprire i bug una volta che questi hanno causato danni. Al di là dei numerosi esperti di sicurezza, citati nel capitolo, è anche l'opinione di Jay Beale, uno degli sviluppatori di Bastille Linux, espressa in un post su NewsForge: ”Ora, non ti ripeterò alcunché di quel ‘many eyeballs' privo di senso, molto del codice che usiamo non è mai stato rivisto sistematicamente. E' perciò arduo dire quale sia l'effetto reale della disponibilità del codice”.

Gli autori ci tengono comunque a sottolineare il loro profondo rispetto per la comunità Open Source; ma, è un dato di fatto che lo slogan dei tanti occhi, preso sic et simpliciter, non sia altro che un mito, anche alla luce dell'esistenza di bug irrisolti per anni in software open source: 15 anni per un buffer overrun in Sendmail; 10 anni per una vulnerabilità da formattazione di stringhe nell'implementazione MIT di Kerberos; 7 anni per un buffer overrun in SAMBA; 5 anni per una esecuzione remota di codice sempre nell'implementazione MIT di Kerberos ed infine, ironicamente, 5 anni e mezzo per un buffer overrun in Fetchmail.

Gli autori evidenziano comunque come anche metodi di sviluppo proprietari, quali il Capability Maturity Model Integration (CMMI), il Team Software Process ed il Personal Software Process (TSP e PSP), dedichino solo una sporadica attenzione alla sicurezza nel processo di sviluppo, né sia possibile dimostrare un misurabile incremento del livello di wsicurezza a seguito della loro adozione; anche un processo ad hoc come i Common Criteria (CC) non definisce, se non nei livelli più elevati, standard per la qualità dell'architettura e del codice, ed è anzi dimostrato come prodotti che hanno ricevuto la certificazione CC non siano immuni da bug di sicurezza: i Common Criteria garantiscono che le caratteristiche legate alla sicurezza di un prodotto abbiano il comportamento desiderato, ma non garantiscono in alcun modo una diminuzione dei bug di implementazione.

La storia della nascita ed evoluzione di SDL, oggetto del terzo capitolo e giunto alla versione 3.0 nel gennaio del 2006 con l'incorporamento dei requisiti di privacy, partendo dal primo nucleo di transfughi della defunta Digital Equipment che creò il kernel NT e passando per l'iniziativa del Trustworthy Computing, che prese le mosse dalla e-mail inviata da Bill Gates nel 2002 a tutti i dipendenti Microsoft, è affascinante, ma sicuramente troppo lunga e discorsiva per riportarla qui. Mi limiterò a citare il paper di ricerca dell'Università della Virginia Comparing Java and .NET Security, che per primo riconobbe come la novella piattaforma .NET avesse fatto tesoro degli errori nella progettazione di Java, ed il tool di analisi statica del codice che vide la luce in quegli anni, PREfast, oggi disponibile come switch di compilazione /Analyze in Visual Studio 2005. Il quarto capitolo è invece interamente dedicato al management che, volendo valutare l'adozione di SDL, debba analizzarne i costi in rapporto ai benefici: come spiegato nella seconda parte, SDL comprende un complesso insieme di attività che impiegano risorse, ed è dunque opportuno stimarne il ritorno. In generale, oltre che per la compliance a specifici standard e per i prodotti che investano la sicurezza, ne viene consigliato l'uso per i sistemi infrastrutturali (sistemi operativi, DBMS, server e-mail e di collaborazione), per l'e-commerce e per le applicazioni LOB (Line-of-Business). In particolare, gli autori ricordano come, dopo l'adozione dell'SDL, la molesta attenzione degli attaccanti si è spostata, in maniera significativa, da SQL Server verso Oracle. Come regola del pollice, il costo di prima applicazione dell'SDL varia dal 15 al 20 per cento in termini di incremento nella pianificazione dei tempi di progetto, una percentuale che diminuisce significativamente se viene applicato ad un prodotto completamente nuovo.

La seconda parte illustra le 13 fasi dell'SDL, dedicando un capitolo ad ognuna. Abbiamo un insieme di fasi ben definite, cui corrispondono dei capitoli molto brevi (in media una decina di pagine), con l'elenco dei passi da compiere, indicazioni di massima per le attività fortemente variabili da un progetto all'altro e l'elenco dei deliverables per ogni fase. In tema di lunghezza, fanno eccezione le due fasi dedicate alla creazione dei modelli di minaccia (threat models), più volte giudicati un componente critico dell'SDL dai due autori e, significativamente, alla risposta alle vulnerabilità che, indipendentemente da ogni sforzo, sopravviveranno nel prodotto finale. Il quinto capitolo è dedicato alla fase iniziale, quella importante del training del team di sviluppo sugli argomenti di sicurezza; gli autori illustrano in grande dettaglio le procedure utilizzate da Microsoft, l'obbligo formativo annuale esteso a tutti i dipendenti dei team di ingegnerizzazione prodotto, e segnalano la disponibilità pubblica di alcuni dei corsi e-learning in materia di sicurezza erogati internamente a Microsoft (il corso base, giova ricordarlo, è sotto forma di video nel CD allegato al testo), oltre alla disponibilità come corso in aula del classico Writing Secure Code.

Nel sesto capitolo vengono descritte le fasi di formazione del team, che si occuperà del coordinamento degli aspetti di sicurezza (il Security Leadership team) e viene in particolare posta estrema attenzione alla figura del Security Advisor, la guida del team lungo tutte le fasi del processo SDL al quale sono richieste grosse doti di leadership e project management, mentre quelle di sviluppatore sono opzionali. Occorre inoltre assicurare che il processo di tracking dei bug includa una serie di informazioni specifiche per i bug di sicurezza, meticolosamente elencate in un apposito paragrafo, e stabilire la bug bar, ovvero il break-even point oltre il quale i costi di adozione di SDL diventano ingiustificatamente alti in rapporto ai benefici. Laddove le pratiche di scrittura di codice sicuro abbondano (e poche di esse vengono seguite, per usare le parole degli autori), mentre vi è una relativa mancanza di linee-guida pragmatiche in termini di progettazione di applicazioni sicure: SDL invece definisce un insieme di pratiche che prende le mosse dal classico paper The Protection of Information in Security Systems e vengono brevemente illustrate nel settimo capitolo, rimandando, per una più approfondita discussione, oltre che a Writing Secure Code ai testi di Anderson e Bishop. I principi illustrati si basano sulla progettazione ed implementazione di componenti piccoli e semplici; sulla separazione e sul minimo privilegio; sull'accettabilità da parte dell'utente finale; sulla validazione di ogni accesso ad ogni risorsa protetta; sull'adozione di configurazioni sicure per default; sulla progettazione aperta e sulla minimizzazione delle risorse condivise. Un'attività peculiare di questa fase è l'analisi e la riduzione della superficie di attacco. In tema di riduzione dei privilegi, se fino ad ora gli sviluppatori avevano fatto affidamento sulla funzione AdjustTokenPrivileges per ridurre i privilegi associati ad un utente, con Windows Vista è possible fare un deciso balzo in avanti, assegnando al chiamante solo i privilegi strettamente necessari tramite ChangeServiceConfig2 (di passaggio, troverete on line l'elenco dei cambiamenti apportati con Vista alla Windows API).

La fase successiva, oggetto dell'ottavo capitolo, è la valutazione dei rischi nello sviluppo del prodotto, con una particolare attenzione per gli aspetti relativi alla privacy; questo breve capitolo riassume molto velocemente alcuni elementi, ma il questionario completo per il security risk assessment è disponibile sul CD allegato al libro. Come già accennato, i modelli di minaccia sono una componente di capitale importanza per SDL, ed alla loro prima stesura, soggetta a revisione lungo tutte le fasi successive, sono dedicate le 32 pagine del nono capitolo. La versione ivi discussa è quella riveduta e corretta alla luce delle obiezioni di Peter Torr, rispetto al modello originario accennato in Writing Secure Code ed illustrato, più compiutamente, in Threat Modeling di Swiderski e Snyder. Il capitolo descrive il procedimento di creazione dei modelli di minaccia, le tecniche di mitigazione del rischio e l'uso dei threat model come guida per le review del codice ed il testing. La creazione dei modelli prende le basi dalla definizione di un modello ad alto livello dell'applicazione tramite i data flow diagrams, che, secondo i dettami di SDL, va aggiornato ogni sei mesi al massimo; nel capitolo viene dettagliatamente illustrato un esempio per l'applicazione Pet Shop 4.0, creata dalla Vertigo Software per illustrare le miglior prassi di sviluppo .NET. L'identificazione delle minacce segue, naturalmente, il modello STRIDE, mentre le ultime versioni di SDL hanno abbandonato il calcolo quantitativo del rischio, sia tramite il classico prodotto probabilità x danno, che mediante il più complesso calcolo DREAD precedentemente adottato, a favore di un approccio qualitativo basato sulla determinazione della bug bar, ovvero del rischio massimo accettabile. Infine, l'incredibile sforzo produttivo richiesto da Windows Vista (un progetto costato tre volte e mezza il lancio dello Shuttle) e la conseguente produzione di centinaia di modelli di minaccia ha portato, secondo i più classici dettami dell'ingegneria del software, all'introduzione di metriche e KSF (Key Success Factors) per la valutazione quantitativa dei threat model.

La creazione di linee-guida prescrittive, documentazione, tool di sicurezza semplici da usare per l'utente finale è l'oggetto del decimo capitolo, che parla anche dell'importanza degli aggiornamenti automatici di sicurezza, oltre a presentare alcune creazioni del team di sicurezza Microsoft quali l'IIS Lockdown Tool ed il Security Configuration Wizard (SCW) di Windows Server 2003 Service Pack 1. L'undicesimo capitolo, di natura più tecnica, tratta invece delle policy per la scrittura di codice sicuro. Il discorso è volutamente di alto livello, giacché alle funzioni insicure, agli standard crittografici minimi ed ai tool ed opzioni dei compilatori sono dedicati tre appositi capitoli nella terza parte di approfondimento del testo, ed investe praticamente solo la creazione di codice C++, con solo un accenno all'operatore checked per prevenire errori di overflow nell'aritmetica degli interi in C#.

Il dodicesimo capitolo illustra invece le tecniche di testing utilizzate in SDL. Una fondamentale importanza rivestono le tecniche di Fuzz Testing con dati malformati, completamente casuali o costruiti secondo pattern che tengono conto del parser sottoposto a test, per le quali sul CD allegato al testo è disponibile un tool in C++, e che hanno permesso la scoperta dal 20 al 25 per cento dei bug di sicurezza nei prodotti Microsoft prima che venissero rilasciati al pubblico (per la maggior parte in codice pre-SDL). Anche con l'aiuto di questa famiglia di tool - fra i quali vengono citati l'Application Verifier e, come prodotto di terza parte, Cenzic Hailstorm - poche organizzazioni al mondo saranno in grado di seguire regole come il test con 100.000 file malformati per ogni formato ed ogni parser supportato; la descrizione delle procedure seguite in quel di Redmond è comunque affascinante e foriera di spunti. Un fuzz test richiede il monitoraggio del processo in esecuzione - operazione eseguibile su Windows tramite i Job Objects - e sussistono analogie, ma anche differenze, con il fuzzing dei protocolli di rete. Il fuzz testing costituisce la gran parte del capitolo; dei brevi paragrafi sono dedicati al penetration testing (pratica che SDL consiglia di affidare, in prima istanza, a società terze parti), alla verifica a run-time, ed all'aggiornamento dei modelli di minaccia e del documento che descrive la superficie di attacco.

SDL prevede una fase di review generale, il Security Push, focalizzata sulla scoperta, non sulla risoluzione, di bug nel codice legacy, ovvero pre-SDL, ed il cui obiettivo finale è, paradossalmente, quello di eliminare la necessità di un Security Push nei successivi cicli di esecuzione di SDL; tale fase, che può partire solo quando lo sviluppo ha raggiunto lo stadio di completamento del codice e delle feature richieste, è oggetto del tredicesimo capitolo. La sua durata, per prodotti del calibro di Windows, Office e SQL Server, non è mai inferiore a sei settimane – statisticamente, scende a tre settimane per i prodotti minori in Microsoft – e comprende, oltre alla review del codice (per quello .NET, viene usato PEVerify per stabilire la parte unmanaged, che non è soggetta al controllo a runtime del CLR), quella della documentazione e, ancora, dei modelli di minaccia. Questa fase è preceduta da una di training e comprende una parte specifica di test di sicurezza. L'ultima fase prima del rilascio, la Final Security Review (FSR), è l'argomento del quattordicesimo capitolo. Si tratta di una parte cruciale e complessa dell'SDL, tanto che in Microsoft non viene eseguita dagli specialisti di ogni gruppo di prodotto, ma in maniera centralizzata dal team di sicurezza dedicato. Ad un questionario preliminare segue l'ennesima review dei modelli di minaccia, la review e la ri-prioritizzazione dei bug di sicurezza, la riesecuzione della validazione tramite tool automatizzati (in particolar modo, viene effettuata l'ispezione formale dei flag di sicurezza nei makefile e negli script di build).

Dopo questa fase, immediatamente prima che il prodotto venga rilasciato, vengono pianificate le procedure di risposta alle vulnerabilità di sicurezza, oggetto del quindicesimo capitolo. Come più volte ricordato, la creazione di software immune da bug è un obiettivo del tutto utopico; uno degli autori, Steve Lipner, negli Anni 80 fu alla guida di un progetto che mirava alla creazione di un sistema operativo che ottenesse la classificazione A1, sicurezza matematicamente verificabile, secondo i vecchi Trusted Computer Systems Evaluation Criteria, ma fallì. A parte ogni altra considerazione, si dovrebbe tenere presente come un'analisi di sicurezza venga effettuata sempre alla luce delle conoscenze attuali in materia, mentre non è possibile tenere in conto le evoluzioni della ricerca sulle vulnerabilità: si pensi solo all'obsolescenza degli algoritmi crittografici o all'overflow nell'aritmetica degli interi, una classe di attacchi precedentemente sconosciuta, che dimostrò la propria pericolosità col rovinoso attacco DoS a Java JNDI/DNS. Il capitolo è perciò assai ampio, una trentina di pagine, e dedica molto spazio all'allestimento del cosiddetto Security Response Center (SRC), all'individuazione delle fonti di report sulle vulnerabilità, alla prioritizzazione ed alla tempistica di risposta: per quanto la tentazione sia sempre quella di rilasciare una patch prima possibile, essa non verrà immediatamente applicata su tutti i sistemi, mentre sarà viceversa oggetto delle malevole attenzioni degli attaccanti che, tramite reverse engineering, cercheranno di scoprire la vulnerabilità cui pone rimedio per sfruttarla tramite attacchi su vasta scala.

Il processo stesso di risposta alle vulnerabilità investe due branche, quella squisitamente tecnica di rimedio alla vulnerabilità e quella di ricezione delle vulnerabilità stesse, di prioritizzazione e di gestione del rapporto con gli scopritori delle flaw (SDL prescrive che vengano contattati dall'SRC entro 24 ore dalla comunicazione della vulnerabilità). Tutte le sottofasi di questo processo vengono analizzate in dettaglio, così come quelle del flusso alternativo di risposta alle emergenze (il Software Security Incident Response Process o SSIRP). Per quanto riguarda il team di sviluppo, le prassi SDL prevedono la creazione di un pool di risposta agli incidenti con reperibilità 24/7, l'ingegnerizzazione per componenti e la loro revisione, l'introduzione di feature di aggiornamento automatico del prodotto (nel caso Microsoft, si è passati nel giro di pochi anni da otto installer a quello unificato di Vista attuale) ed il supporto di tutte le versioni: si pensi solo che di Internet Explorer, tenendo conto del numero di versione oltre che della localizzazione, ne esistono 425. Il sedicesimo capitolo, quello dedicato alla fase di rilascio vera e propria, comprende una sola fase: fondamentalmente, l'unica attività della release, dal punto di vista della sicurezza, è l'upload sul sito interno di progetto dei simboli di debug. Breve è anche il diciassettesimo capitolo dedicato all'ultima fase di SDL, l'esercizio del processo di risposta agli incidenti; vengono date molte prescrizioni pragmatiche sulla gestione del rapporto con gli scopritori delle vulnerabilità, che SDL impronta alla massima disponibilità, cooperazione ed amichevolezza anche con i ricercatori che seguono un approccio non responsabile di divulgazione pubblica della vulnerabilità prima che sia stato approntato un rimedio per la stessa.

La terza parte del testo ha carattere di approfondimento, e presenta materiale di riferimento in special modo per le pratiche di scrittura di codice sicuro. Come accennavo in apertura, i metodi agili come eXtreme Programmino (XP) e Scrum stanno guadagnando sempre più popolarità; la stessa Microsoft ha aggiornato la versione 4.0 del proprio ciclo di sviluppo per includervi MSF for Agile Software Development, ma esistono ad oggi poche guide prescrittive per incorporarvi attività di sicurezza. Sulla scia dell'esperienza acquisita incorporando le metodologie agili nei progetti di MSN e Windows Live, il diciottesimo capitolo mostra come integrare le prassi di SDL nei metodi di sviluppo agile. Esso è suddiviso in due parti: la prima è incentrata su come seguire l'intero ciclo SDL adottando un metodo di sviluppo agile e viceversa, e la seconda mostra come incorporare alcune pratiche SDL in un siffatto metodo, e come SDL possa essere adottato anche da chi non ha le sterminate risorse Microsoft.

Le prassi di training sono applicabili sic et simpliciter, mentre nella fase di project inception un security coach può agevolmente prendere il posto del Security Advisor; visto il ruolo critico di questa figura in SDL, però, si consiglia di seguire con molta cautela il principio di rotazione delle figure adottato in XP. L'aspetto del simple design trova un immediato riscontro in SDL ed, anzi, per i citati progetti MSN sono state adottate alla lettera le sprint di Scrum. Per quanto riguarda le user story, per progetti infrastrutturali come MSN e Windows Live era de facto impossibile avere un rappresentante del cliente nel team di sviluppo, ma sono state invece adottate le personas. Un minimo di adattamento (descritto nel testo) è richiesto per l'analisi dei rischi, un cardine di SDL per il quale le metodologie agili non prevedono certo la creazione delle DFD; occorre lavorare sulle design sprint previste da qualche metodo e sulle stories, che mostrano le interazioni fra componenti.

Lì dove l'integrazione fra SDL ed i metodi agili è più forte è nell'adozione delle prassi di sviluppo sicuro del codice e, soprattutto, nel testing; il Test-Driven Development sembra essere stato inventato apposta per le pratiche di fuzz testing e bug fixing, ed il novello Visual Studio Team System fornisce un validissimo aiuto con le check-in policy e le feature di Web testing; allo stesso modo, le pratiche di refactoring favoriscono singolarmente l'eliminazione dei bug di sicurezza. Bisogna porre attenzione al fatto che il security push può essere eliminato se si seguono pratiche di sviluppo agile, tranne in un caso: la revisione del codice legacy. Se come metodologia di sviluppo si usa Scrum, è possibile effettuare la pulizia del codice legacy nel product backlog; i team di MSN effettuano comunque un security push in forma ridotta, di un giorno per le sprint quindicinali e di due per quelle di un mese, prima di ogni Release Candidate.

Allo stesso modo, non è opportuno seguire una completa Final Security Review quando si sviluppa con le metodologie agili, ma viene definito un set minimo di requisiti da seguire; viene inoltre raccomandato l'uso delle Big Visible Chart (BVC). La fase di risposta alle vulnerabilità di sicurezza può essere effettuata con uno spike, ma vi è in questo caso una divergenza fra SDL e metodi agili in quanto uno spike è pensato per risolvere un singolo problema tecnico, mentre SDL prevede una serie di analisi di regressione per rilevare la presenza di altre istanze della vulnerabilità nel prodotto. Sussistono presupposti analoghi quando si vuole, viceversa, incorporare alcune delle prassi SDL nei metodi di sviluppo agile; è opportuno adottare in maniera sistematica i constraints nelle user story, a causa dell'assenza di specifiche i tool di sviluppo e test assumono importanza critica, e nell'adozione del refactoring bisogna prestare particolare attenzione alla introduzione di errori di regressione.

Col diciannovesimo capitolo, dedicato alle chiamate a funzione il cui uso è proibito da SDL, comincia una serie di tre capitoli dedicata agli aspetti pragmatici della scrittura di codice sicuro, che hanno molti punti in comune col precedente Writing Secure Code. La lista delle API banned comprende un lungo elenco (fornito sotto forma di header file nel CD allegato al libro) dalla C runtime library, ed è focalizzata quasi esclusivamente sulle funzioni, che possono portare ad un buffer overrun. Il testo illustra l'uso alternativo delle librerie StrSafe e Safe CRT (quest'ultima è caratteristica di Visual Studio 2005), ma ricorda che un semplice trova e sostituisci non garantisce al 100% la sicurezza del codice finale, ed è sempre necessario verificare, in particolar modo, la grandezza del buffer di destinazione. Il capitolo fornisce, inoltre, alcuni criteri di scelta fra le due librerie; in particolare, le Safe CRT non possono essere usate in kernel mode, ma le StrSafe non forniscono alcun sostituto per itoa.

Il ventesimo capitolo è dedicato agli standard crittografici minimi richiesti da SDL. La prima, banale ma quanto mai utile, prassi da seguire è quella di non creare mai proprie librerie o, peggio, algoritmi crittografici, ma utilizzare i protocolli standard inclusi in System.Security.Cryptography per codice .NET, nella CryptoAPI per il codice C/C++ (ed, in prospettiva, pensare alla CNG API di Vista) e nella CAPICOM per il codice di scripting. Un altro principio consigliato dal testo è la cryptographic agility, ovvero la prassi di incorporare gli algoritmi utilizzati, non nel codice ma in store configurabili come il registro o un file XML, protetti da adeguate ACL, onde favorirne la sostituzione con l'evoluzione della ricerca crittografica. Il capitolo si chiude con una serie di prescrizioni su algoritmi simmetrici ed asimmetrici e relativa lunghezza delle chiavi, funzioni hash, MAC, storage dei dati tramite Data Protection API (DPAPI) e generazione di numeri casuali; fondamentalmente, occorre fare riferimento alla tabella riassuntiva che elenca gli algoritmi e le lunghezze delle chiavi da rimpiazzare, utilizzabili per il solo codice già esistente e da utilizzare per il nuovo codice.

L'elenco dei tool e delle opzioni di compilazione il cui uso è obbligatorio in SDL forma l'oggetto del ventunesimo capitolo. Molti degli argomenti sono già stati trattati, in maniera sparsa, nei capitoli precedenti, ma il capitolo funge da punto di riferimento per chi preferisca utilizzare il testo come riferimento alla lettura sequenziale. Il focus è, oltre che sulle opzioni di Visual Studio 2005, su tre tool liberamente scaricabili: PREfast, FxCop ed Application Verifier. Il tool di analisi statica PREfast è specifico per il codice C/C++ e, come già ricordato, è oggi disponibile come opzione di compilazione /analyze in Visual Studio 2005; produce una serie di warning per ognuno dei quali il capitolo propone, in forma tabellare, la descrizione ed un esempio di codice insicuro da correggere. FxCop è viceversa specifico per il codice .NET managed, e segnala le difformità rispetto alle linee-guida di progettazione Microsoft per il codice .NET; anche qui, il testo fornisce un lungo elenco delle regole di conformità che il codice sottoposto ad FxCop deve soddisfare, pena la non-conformità ad SDL. Application Verifier, infine, come già ricordato, a differenza dei due precedenti non è un tool di analisi statica, ma rileva errori di esecuzione a runtime, ed è specifico per codice unmanaged, ovvero non-.NET. Nello specifico, Application Verifier (fornito con il Platform SDK e direttamente in Visual Studio 2005) monitora le interazioni fra l'applicazione e la piattaforma Windows sottostante (intercettando le chiamate a funzione) ed, in particolare, l'uso degli oggetti del kernel, del registro, del file system e delle API Win32. Si tenga presente che la versione scaricabile liberamente e quella inclusa in Visual Studio 2005 di Application Verifier sono differenti: la versione stand-alone ha una curva di apprendimento più ripida (in Visual Studio 2005, Application Verifier è una semplice opzione di compilazione), ma anche molte più opzioni. Il capitolo si chiude con l'elenco delle versioni dei compilatori e le opzioni da usare per la compliance ad SDL.

Nel ventiduesimo ed ultimo capitolo viene discussa l'analisi delle minacce secondo il modello STRIDE utilizzando i threat trees, esclusa per semplicità dal nono capitolo. Il capitolo è ragionevolmente lungo (una ventina di pagine), ma è inteso più che altro a scopo di consultazione o, meglio, come checklist: per ognuna delle sei minacce del modello STRIDE, e per ognuna delle quattro classi di elementi di un DFD, ove applicabile viene presentato il relativo albero delle minacce, presentando in forma tabellare l'elenco dei nodi foglia dell'albero e le relative prassi di sicurezza da adottare in fase di progettazione e testing. Questo capitolo è anche ricco di riferimenti tecnici ed esempi di pattern di attacco, che troverete nella bibliografia finale.
proMolto positvo è il riferimento finale sul processo di sviluppo sicuro maturato all'interno dell'organizzazione Microsoft a partire dal 2002, ricco anche di suggerimenti per l'adozione di prassi di sviluppo sicuro in realtà che non hanno le risorse di Microsoft stessa.
controNessuno in particolare.
Precedente: Dual booting con Windows XP e Vista
Successiva: Alcuni trucchetti per velocizzare i programmi Perl
Copyright Programmazione.it™ 1999-2014. Alcuni diritti riservati. Testata giornalistica iscritta col n. 569 presso il Tribunale di Milano in data 14/10/2002. Pagina generata in 0.334 secondi.