Si sente spesso parlare di evoluzione delle minacce, ed è sicuramente una tematica degna di attenzione. Non sono solo le minacce, però, a cambiare nel tempo: anche le classi di vulnerabilità hanno la loro vita e storia.
Anch’esse cambiano di importanza e significato se collocate in un periodo storico preciso. Una classe di vulnerabilità può non esistere (ovvero non essere ancora stata scoperta) un giorno e diventare una piaga il giorno dopo. La medesima vulnerabilità dopo un certo periodo di tempo può diventare inoffensiva perché le tecniche di exploiting sono state mitigate e/o rese inapplicabili.
Indice degli argomenti
Vulnerabilità software: un esempio pratico
Prendiamo ad esempio le vulnerabilità di tipo SQL Injection: sono state scoperte all’incirca 15 anni fa, non hanno avuto la dovuta attenzione per alcuni anni e poi ci si è accorti che potevano essere molto pericolose. Una volta realizzata la loro pericolosità e la loro efficacia sono cominciati gli attacchi su larga scala.
Identificare ed exploitare le SQL Injection è estremamente semplice e l’impatto è abbastanza devastante in quanto è possibile, in molti casi, accedere a dati protetti ed in alcuni casi eseguire codice arbitrario sul server ospite.
Quindi, in un certo momento storico, ci si è trovati con una tipologia di vulnerabilità estremamente pericolosa e, nonostante sia piuttosto semplice evitare di introdurla nel codice, è stata una vera e propria piaga per decenni.
Ad oggi, per fortuna, le vulnerabilità di questo tipo stanno pian piano scomparendo: anzi, possiamo dire che nel codice sviluppato negli ultimi anni è quasi difficile trovarne. La cosa interessante però è capire perché stiano scomparendo in un tempo relativamente breve dopo dieci anni di presenza massiva. Personalmente riesco ad identificare due motivi principali:
- l’adozione di framework da parte degli sviluppatori;
- istruzione dei programmatori su questioni di sicurezza.
Framework di sviluppo e formazione degli sviluppatori
I framework, in particolare, sono strumenti che automatizzano e semplificano l’utilizzo dei moderni paradigmi di programmazione anche limitando il potere di azione del programmatore ed impedendogli così di commettere gli errori più comuni.
Un buon esempio sono gli ORM (Object Relational Mapping) che consentono l’accesso a database relazionali senza l’utilizzo di query SQL, ma fornendo un meta-linguaggio semplificato e dotato di controlli di sicurezza aggiuntivi.
L’istruzione dei programmatori, inoltre, permette loro di rendersi conto di cosa siano gli errori. Voglio dire, un programmatore non erudito non sa che introdurre una SQL Injection nel codice è un errore. E in effetti come dargli torto? Il suo codice funziona lo stesso e fa tutto quello che deve fare: il problema è che non fa solo quello per cui è stato programmato, ma anche altre “cose” che sfuggono al controllo del programmatore ma, ovviamente, non al controllo di un eventuale attaccante.
Quindi, considerando che i framework non sono una soluzione al 100% (è possibile introdurre SQL Injection anche usando un ORM) la cosa più importante è che chi sviluppa il codice sia cosciente di ciò che il suo codice può fare, in questo caso il framework diventa uno strumento per fare meglio e più rapidamente quello che si sa già fare.
Una frase tipo “il mio software è sicuro perché ho usato un framework” proprio non si può sentire. Sarebbe come dire “vado in macchina e non mi succederà nulla perché uso la cintura”. Si rischia di confondere un aiuto con una soluzione.
Consigli di sicurezza per chi produce e acquista software
Cosa dovrebbero dunque fare le aziende per produrre software il più sicuro possibile? In primis dotarsi degli strumenti corretti (ad esempio un buon framework di sviluppo) ed evitare complessità inutili o il rischio di “reinventare la ruota”.
Inoltre, i giusti strumenti sono anche un buon modo per cominciare ad istruire le persone. Una volta creato l’ambiente adatto bisogna cominciare a formare le persone. In realtà formare le persone è la chiave: anche uno strumento potente e sicuro, in mano ad uno stolto, può creare grossi danni.
Purtroppo, per quanto ho potuto constatare in anni di attività, le aziende non sono propense ad offrire corsi di formazione ai dipendenti, specialmente se si tratta di cyber security. La formazione viene spesso vista come un costo privo di un ritorno.
Cito una frase che ho letto tempo fa: “CFO: cosa succede se paghiamo la formazione e poi i dipendenti ci abbandonano? CTO: e cosa succede invece se non la paghiamo e i dipendenti restano?”
Le aziende che producono software devono cominciare a formare i programmatori (se li si forma bene saranno in grado di scegliersi da soli un framework e crearsi il loro ambiente di sviluppo sicuro).
Le aziende che invece comprano software (ovvero tutte le alte aziende) devono scegliere i fornitori inserendo nell’equazione anche la variabile sicurezza, ovvero domandarsi “Quanto il fornitore che ho scelto è edotto sulle questioni di sicurezza?”.
Concludo con una frase che ripeto sempre: “per un ingegnere il software che ha sviluppato funziona quando fa quello per cui è stato progettato, per un bravo ingegnere il software che ha sviluppato funziona quando fa solo quello per cui è stato progettato”.
