In un mondo in cui i criminali informatici diventano ogni giorno più scaltri, e le conseguenze di un furto di dati possono portare alla distruzione di un'azienda, è evidente che la sicurezza è un fattore cruciale quando si parla di sviluppo del software.
Peraltro, le complessità delle attuali minacce proibiscono di pensare alla semplice aggiunta di un livello di sicurezza nella fase finale del progetto, e di fare affidamento sui tests prima che il progetto stesso entri in produzione, perché si tratterebbe in ogni caso di misure ampiamente insufficienti.
Bisogna far diventare la sicurezza, e tutti i tests associati alla sicurezza, una parte integrante del processo di sviluppo, per poter puntare a un risultato in linea con le aspettative.
Ed invece, moltissime aziende non riescono a raggiungere questo obiettivo, in quanto si tratta di un processo molto più facile da descrivere che da mettere in atto.
Ignorare la sicurezza significa assumersi le proprie responsabilità
Prima di tutto, esaminiamo le conseguenze a cui va incontro un'azienda se il proprio software non è sicuro oppure è vulnerabile.
Il rischio più grande, ovviamente, è quello della penetrazione all'interno dei servers e del furto dei dati. Gli effetti di questi eventi sono spesso catastrofici, in quanto si associano costi interni per la perdita della produttività a costi esterni per la soluzione del problema, oltre all'impatto devastante della perdita di credibilità e di fiducia da parte degli utenti.
Con il rapido aumento del volume dei dati, e i criminali informatici che diventano sempre più sofisticati, i costi possono solo salire.
Un report di Ponemon Institute ha rivelato che – nonostante un aumento della spesa per la sicurezza da parte delle aziende, che è arrivata a 46 miliardi di dollari – il numero delle intrusioni è cresciuto del 20% e il costo medio di ciascuna intrusione è cresciuto del 30%.
Questo dimostra che la spesa per la sicurezza viene concentrata nel punto sbagliato, ovvero sulla sicurezza perimetrale e sull'infrastruttura, i due punti che i criminali informatici sanno come aggirare, per cui le aziende devono evolvere per far fronte alle nuove minacce con un approccio proattivo.
Se le conseguenze sono così disastrose, perché la sicurezza continua a essere affrontata solo nell'ultima parte di un progetto? Spesso, sono i vincoli di tempo e di budget a impedire che venga considerata una priorità.
Con questo approccio, però, è possibile effettuare solamente un rapido test di penetrazione prima di andare in produzione, e questa mancanza di “due diligence” spesso si trasforma in vulnerabilità facili da sfruttare da parte dei criminali informatici.
Fare tutti i passi necessari
La sicurezza deve essere proattiva piuttosto che reattiva, deve partire durante il ciclo di sviluppo del software, e deve essere continuamente testata e misurata durante tutto il ciclo di vita.
Tutto questo parte dalla definizione di parametri di sicurezza sia funzionali che non funzionali, il che si traduce in un progetto su cui gli specialisti dei test di sicurezza possono operare utilizzando il loro approccio (ovvero, simulando il comportamento dei criminali) e applicare i modelli delle minacce informatiche, per assicurare che siano presenti tutte le misure contro gli attacchi.
Durante tutto il processo la programmazione deve essere tenuta sotto controllo e analizzata, per verificare che i problemi siano stati risolti prima di passare alla fase successiva.
Poi, durante la fase di test, gli specialisti possono cominciare ad attaccare il sistema per portare allo scoperto le vulnerabilità o i problemi più comuni.
Questo significa che i test di penetrazione conclusivi (eseguiti da una terza parte indipendente) non dovrebbero essere che una verifica di routine, e non dovrebbero ritardare il rilascio per la presenza di problemi di sicurezza che non sono stati ancora affrontati e risolti.
In ogni caso, sapere cosa fare è solo il primo passo.
La sfida più importante è quella di verificare che i test sulla sicurezza vengano eseguiti durante ogni fase dello sviluppo, perché tutta l'organizzazione è allineata sullo stesso obiettivo e anche il management comprende i motivi per cui la sicurezza è un elemento fondamentale del processo.
La responsabilità della sicurezza e dei test non dovrebbe ricadere solo sulle spalle del team di sviluppo, ma dovrebbe essere condivisa a tutti i livelli dell'organizzazione, e sostenuta da chi detiene i budget di spesa.
Fortunatamente, esistono strumenti che permettono di tenere sotto controllo il processo dall'inizio.
L'Open Software Assurance Maturity Model (OpenSAMM) è un framework aperto e indipendente che aiuta le organizzazioni a strutturare e implementare una strategia per la sicurezza del software personalizzata in base ai rischi specifici del proprio settore, per cui una pubblica amministrazione avrà esigenze diverse da quelle di una finanziaria o di un'azienda in franchising.
Le risorse fornite da OpenSAMM permettono di valutare le pratiche di sicurezza esistenti, e di sviluppare un programma bilanciato in grado di apportare dei miglioramenti concreti al programma di assicurazione della qualità e definire – e misurare – le attività legate alla sicurezza all'interno dell'organizzazione.
Cominciare i progetti dalla sicurezza dovrebbe essere l'opzione più semplice, perché è quella che permette di risparmiare tempo e denaro, e proteggere l'azienda e le informazioni degli utenti dai rischi più importanti. Come abbiamo già detto, però, la sfida più importante è quella di portare tutta l'azienda a “pensare” in termini di sicurezza, soprattutto quando si parla di sicurezza del software.
Peraltro, le aziende che rimangono indietro senza cambiare il proprio atteggiamento rispetto alla sicurezza sono quelle che rischiano di assistere a un collasso dei propri sistemi IT sotto agli attacchi sempre più sofisticati ed efficaci dei criminali informatici.
di Riccardo Brizzi, Chief Operating Officer di SQS
