Negli ultimi tempi ho notato che a fronte della domanda
"come assicurate la sicurezza delle applicazioni?" mi viene risposto:
"facciamo dei vulnerability assessment, dei penetration test e delle code
review". Peccato che queste pratiche siano realizzate a fine lavori (in
rari casi, anche in fasi intermedie), mentre la sicurezza andrebbe considerata
sin dall'inizio, quando si stabiliscono i requisiti funzionali, si progetta il
software e la sua architettura e si scelgono gli strumenti di sviluppo e i
compilatori; un poco dopo, ma sempre prima dei VA-PT-CR, si dovrebbero
stabilire degli standard di codifica.
Perché quindi in molti riducono la sicurezza applicativa
ai VA-PT-CR? Provo con delle deduzioni, ma è bene precisare che si applicano a
coloro che veramente intendono assicurare un buon livello di sicurezza alle
applicazioni; non è questa un riflessione sul perché molti non si interessano all'argomento.
In molti riducono la sicurezza applicativa ai VA-PT-CR
perché:
1- i venditori dei servizi di VA-PT-CR sono molto più
bravi dei venditori dei servizi di sicurezza a supporto dell'analisi,
progettazione, sviluppo e realizzazione dei software;
2- quasi nessuno offre buoni servizi di sicurezza a
supporto dell'analisi, progettazione, sviluppo e realizzazione dei software; i
tecnici migliori e più preparati si dedicano a fare VA-PT-CR, anche per
attitudine (è molto più divertente cercare di bucare un'applicazione che
scrivere documenti o scrivere codice); questa non è una critica, ma una presa
d'atto delle diverse attitudini di ciascuno;
3- in effetti, chi offre servizi di sicurezza a supporto dell'analisi,
progettazione, sviluppo e realizzazione dei software o è un consulente con pochissima
conoscenza tecnica dello sviluppo (e quindi si limita a dire "individuate
i requisiti di sicurezza fin dalla fase di analisi" senza poi dare
ulteriori consigli), oppure riduce il tutto all'OWASP Top 10 (che riguarda
alcuni aspetti della progettazione e non dell'analisi e dello sviluppo);
4- gli sviluppatori sono orientati a realizzare
funzionalità, non la sicurezza; quindi è ben lontano dalla loro mentalità
affrontare questo argomento sin dall'inizio;
5- i libri che trattano di questi argomenti sono
pochissimi, molto voluminosi e molto costosi; ottime scuse per evitare di
affrontarli, sia per gli sviluppatori (che quindi preferiscono affidarsi ad
esterni che, per il punto 1, vendono solo VA-PT-CR) sia per i consulenti (che
vendono già altri servizi più "di moda" senza doversi impegnare in
una nuova materia difficile e poco richiesta).
Per dimostrare ulteriormente il punto 2, si osservi
l'andamento dei progetti OWASP (owasp.org): la testing guide è stata aggiornata
nel 2007, 2008 e 2014. La development guide, invece, è stata scritta
inizialmente nel 2002, aggiornata nel 2005 e poi basta, anche se da diverso
tempo stanno lavorando ad una nuova versione.
