Si, ancora il grande Michael Howard che presenta una vera raffica di consigli per gli sviluppatori.
Il punto di partenza è che la security non si può vendere come feature ma è necessario aprire gli occhi e valutare quanto potrebbe costare un eventual exploit dell'applicazione.
Il primo consiglio pratico dovrebbe essere noto a tutti: non fidsarsi mai dei dati che arrivano alla nostra applicazione. "Data is evil" è meglio di qualsiasi altra spiegazione.
Poi un consiglio d'oro che viene ripreso più volte durante la sessione: nel codice non bisogna mai cercare condizioni per cui uscire se non sono valide, ma sempre e solo le condizioni per cui è sicuro continuare a processare i dati. La slide delle 4 ï" in turco è più che mai emblematica.
Poi arriva il consiglio di usare i tools di fuzzing che forniscono input randomico alla nostra applicazione. I tool possono fornire un input 'dump' (totalmente casuale) oppure 'smart' cioè che conoscono il formato dei dati e randomizzano precise parti dei nostri dati (per esempio Microsoft crea in modo automatico file file mp3, wmv etc. corrotti per testare media player). I test vanno ripetuti almeno 100'000 volte e ripetuti se c'è anche solo un fallimento.
Sempre per il fuzzing, Michael consiglia di costruire un "evil layer" che spari dati corrotti. Per esempio RPC ha un evil layer per testare a fondo RPC nella rete.
Poi si passa al threat modeling che è il primo obbligatorio passo che un architetto deve affrontare quando inizia una nuovo progetto.
Quindi si passa ad una lunga lista di elementi da prendere in considerazione per decidere da quale codice cominciare ad eseguire la review di sicurezza.
Si termina poi con una serie di altri consigli tra cui quello di non usare algoritmi crittografici basati su stream o ECB a meno che non ci siano dei requisiti specifici in tal senso.
Nulla da dire se non impeccabile e per l'enorme esperienza che Michael dimostra in tutti i suoi esempi.