Se dovete gestire un team di sviluppatori, fra i problemi più ricorrenti troviamo la sicurezza del codice di programmazione. Molte organizzazioni hanno percorso un lungo cammino formativo negli ultimi anni, ma non hanno ancora acquisito l’idea che la sicurezza è una priorità nello sviluppo.
Il problema alla base è semplice: la maggior parte degli sviluppatori è molto brava in ciò che fa – la scrittura del codice – ma non sono esperti di sicurezza. In pratica, moltissimi conoscono i principi fondamentali della codifica di sicurezza, quali ad esempio:
- Eseguire una validazione di base dell’input
- Ove possibile, controllare i buffer overflow
- Cifrare i dati in transito
- Se può sorgere qualche dubbio, usare il principio del privilegio minimo
Indipendentemente dal fatto che si tratti di un penetration test o un’analisi del codice sorgente, la maggior parte di questi elementi di sicurezza è di pertinenza di molte applicazioni. Il problema è che la sicurezza nelle applicazioni non si spinge molto più in là.
Ci sono debolezze nell’autenticazione, difetti nella logica dell’applicazione e problemi nella validazione avanzata degli input che molti sviluppatori non hanno né il tempo per affrontarli né gli strumenti necessari. Indipendentemente dal fatto che gli sviluppatori abbiano o meno familiarità con la sicurezza, questi difetti sono difficili da individuare e creano rischi aziendali di tale portata che nessuno può permettersi di ignorare.
Ma come si può sapere se gli sviluppatori disponibili sono all’altezza della situazione e si stanno correttamente dedicando alla scrittura del codice, valutando la sicurezza lungo tutto il percorso di sviluppo?
Come accade la maggior parte delle volte che si lavora con altre persone, avrete sicuramente avuto modo di sperimentare cosa significa operare efficacemente su un lungo periodo di tempo. Saprete perciò che è fondamentale educare tali persone e, in un caso come il nostro, cambiare il modo che hanno di rapportare la sicurezza al loro lavoro. Non potrete certamente forzare ogni sviluppatore a imparare tutto d’un tratto la sicurezza e a risolvere ogni problema presente nelle applicazioni. Ma qualche azione può essere intrapresa:
Trovate qualcuno che sostenga la vostra causa. Ci sarà sicuramente almeno uno sviluppatore che è moderatamente interessato a migliorare la sicurezza del software.. Affidate a questa persona la responsabilità di guidare gli sforzi degli altri e di stimolarli sullo sviluppo e sulle questioni inerenti cosa cercare e come fare le cose meglio.
Coinvolgete il top management. Una cosa è avere un manager di medio livello che spinge per avere una migliore sicurezza del software, ma un’altra è quando qualcuno nel management esecutivo si aspetta di trovare tale sicurezza. Quando un manager di alto livello, si aspetta del software sicuro, otterrà l’attenzione del product manager, del project manager, degli sviluppatori e del team di sicurezza e questo aiuta a far accadere le cose.
Coinvolgere gli sviluppatori in riunioni di sicurezza e viceversa. Invece di creare barriere tra gli sviluppatori e lo staff di sicurezza, fateli lavorare insieme. Sia che si tratti di sessioni di pianificazione dello sviluppo, di meeting del comitato sulla sicurezza o di qualsiasi altra cosa, almeno un esponente di ogni team deve essere al corrente dell’attività degli altri. Questo aiuta a garantire che ciascuno lavori nel modo corretto al medesimo progetto e che le attese siano riposte in modo adeguato. Le aspettative non realistiche sono alla radice della maggior parte dei problemi che sorgono in seno alla sicurezza.
Mostrate agli sviluppatori cosa può accadere quando vengono sfruttati i difetti del software. Non crediamo si possa ottenere la sicurezza infondendo paura, incertezza e dubbi, crediamo invece nell’efficacia di mostrare alle persone ciò che può accadere nel mondo reale. Alcuni buoni scanner di vulnerabilità, tool di analisi del codice sorgente e per il penetration test manuale sono un ottimo modo per dimostrare che il software che si sta rilasciando non è come dovrebbe essere. Tutto ciò che serve è un paio di schermate che mostrino le tabelle di un database estratte attraverso un injection SQL, i comandi di prompt da sistemi remoti ed exploit simili per ottenere una maggiore attenzione da parte dei tecnici.
Mostrate – e procurate- i tool di cui hanno bisogno gli sviluppatori. Molti sviluppatori non sono ancora a conoscenza degli strumenti che possono essere utilizzati internamente per trovare falle di sicurezza durante le fasi di sviluppo e di verifica. Molti strumenti, come ad esempio Klocwork K7 e HP Software DevInspect e QAInspect, possono essere collegati in mainstream IDE per avere un processo di test della sicurezza senza soluzione di continuità.
Fornite loro la formazione necessaria. Una cosa è utilizzare il più “reattivo” tool per il testing di sicurezza e tutta un’altra cosa per gli sviluppatori è sapere esattamente cosa non devono fare. Ciò richiede una formazione su base periodica.. Organizzate delle classi per la codifica sicura, conferenze sulla sicurezza o suggerite alcuni buoni libri sulla codifica della sicurezza. Impostate degli obiettivi e legate gli sviluppatori ai risultati attraverso la loro valutazione/premio annuale.
Stabilite standard di sicurezza. Piuttosto che andare indietro e rimediare a guai del passato, definite requisiti interni che stabiliscano che tutto il nuovo codice debba aderire a specifici standard di sicurezza. Un buon riferimento per iniziare con le applicazioni per il Web è l’OWASP Top Ten Project. Certo, non tutti i nuovi software in fase di sviluppo sono focalizzati sul Web come la Top Ten dell’OWASP, ma una grande percentuale lo è e molti degli stessi concetti si applicano direttamente alle applicazioni client/server standalone.
