Dato che il target sono i developer la sessione sarà targhettizata sui developer (non condivido ma il marketing comanda )

La sicurezza è un punto sulla scala di grigi tra il bianco e il nero, nulla può essere al 100% sicurotutto dipende dal contesto (sia le necessità di sicurezza che le aspettative).

Dogma 1: On by Default!
Una feature di sicurezza deve essere attiva per impostazione predefinita altrimenti abbiamo già fallito!

Ma attenzione anche qui un compromesso, se la feature è talmente "feature" da rompere totalmente la retrocompatibilità rischia di avere un impatto tale da essere totalmente ignorata: non funziona più nulla, però è sicuro...

Che cosa è SDL: una metodologia, un processo, un insieme di guidelines. L'obiettivo? ridurre il numero di vulnerabilità da un lato e dall'altro ridurre la pericolosità di quelle che restano.

Le statistiche dicono che se autmenta la qualità del software non aumenta la sicrurezza dello stesso, e questo è in controtendenza con quello che la gente pensa.

Dogma 2: "SALAYC": Suck as less as you can...
Forse è impossibile portare il numero delle vulnerabilità a zero, ma è fondamentale lavorare per tendere a zero! Quindi le vulnerabilità ci saranno sempre, ma devo lavorare per ridurle al massimo.

Una tecnica? modularizzare al massimo al fine di poter attivitare / disattivare feature in questo modo posso ridurre la superficie d'accatto, un ottimo esempio sono IIS6 e IIS7 dove di default tutto è disattivato, ma soprattutto è disattivabile cosa che non si poteva fare con IIS5.x

Ci sono funzionalità che hanno fatto il loro tempo, non è pensabuile adeguarle ai threat attuali, semplicemente sono da bannare (punto).

Stiamo entrando nella parte da veri DevGuri, quindi io mi tiro fuori ... ma Raff qui di fianco a me continua ad annuire....ok torniamo sulla terra e il fuoco si sposta sulla crittografia e i suoi algoritmi.

Dogma 3: Be Crypto Agile:
bella le definizione, non scopire mai nel codice nulla relativo alla crittografia, nulla nemmeno i provider, factory a nastro e portare il tutto a livello di configurazione, se scolpisco e ciò che ho scolpito viene sfondato vengo sfondato anche io... e non è bello

Dogma 4: Evitare come la peste le ACL "deboli":
portano solo ad un falso senso di sicurezza e fanno si che il livello di attenzione cali.

Dogma 5: I tool non fanno il codice sicuro:
Aiutano, questo è sicuro e di certo non è poco, ma non fanno loro il codice sicuro... quindi fate in modo che la vostra guardia non si abbassi perchè tanto avete il tool...

Dogma 6 (o forse 0...): Non c'è nulla di speciale nella sicurezza, fa solo parte della strada che dobbiamo percorrere per portare a termine il lavoro:
Non aggiungo commenti... semplicemente evidente.

Dogma 7: educazione alla sicurezza di tutto il team:
partendo dal presupposto che per tutti la sicurezza sia una sconoscita, e ogni tanto lo è eccome, in questo modo però non date nulla per scontato e non abbassate le difese con la convinzione che un determinato argomento faccia già parte del bagaglio di esperienze del vostro gruppo.

la sicurrezza e "lo stare in piedi" (trad. di Raff...) come si conciliano? benissimo, tranne in un caso se il Security Log si riempie ne segue un BSOD... e questo è by design perchè...

Dogma 8: non ha senso eseguire qualcosa di cui non è possibile controllare la sicurezza.

Una veloce carrellata sulle "solite" cose, che però evidentemente non vengono recepite... SQL Injection Cross Siste Scripting e via dicendo.

Decisamente ne è valsa la pena, veramente una bella sessione!

.m