Per un software sicuro, la PA riveda il rapporto con il fornitore: ecco come
30 Novembre 2015
Matteo Meucci, Owasp
Quali sono le difficoltà di implementazione dei processi di Sicurezza del Software per le aziende italiane ed in particolare per le PA? Ad oggi solo alcune aziende nel panorama italiano possono vantare una maturità nella Governance della sicurezza del software. Perchè?
Partiamo dall’inizio: che cosa intendiamo per Software Sicuro?
Prendiamo come esempio Google mail, un’applicazione che utilizziamo tutti i giorni e chiediamoci: è sicura? Alcune persone potrebbero dire: “Certo che è sicuro, è Google!”. Altri potrebbero affermare: “Sicuro! Guarda il lucchetto in basso a destra quando ti connetti al servizio”. Purtroppo la realtà è ben diversa, basta cercare su un motore di ricerca “Gmail vulnerabilities” ed accorgersi che sono state pubblicate svariate vulnerabilità sull’applicazione. Il lucchetto in basso a destra ci dice solo che stiamo comunicando con il server corretto e che inviamo le informazioni in maniera riservata dal nostro browser ai server di gmail: ma non dice assolutamente niente su come l’applicazione è stata sviluppata. Quello che possiamo dire oggi è che la sicurezza del Software non esiste: qualsiasi software con cui interagiamo tutti i giorni è esposto a possibili vulnerabilità, le applicazioni bancarie così come quelle della PA non sono da meno.
Come può una PA gestire la sicurezza delle applicazioni di oggi? Esiste un ente, una organizzazione in grado di supportare le imprese a sviluppare, mantenere e acquistare il software sempre più sicuro?
Il primo principio di sicurezza del software afferma che le vulnerabilità nel processo di sviluppo del software sono attese. Il controllo dei bug di sicurezza e difetti nel software dovrebbe essere considerato come parte del processo di sviluppo del software. Le aziende tendono a effettuare numerose verifiche di sicurezza del software una volta acquistato il prodotto stesso oppure una volta rilasciato online. Questa pratica andrebbe effettuata prima, per evitare di pubblicare servizi senza neanche avere effettuato un’analisi di sicurezza. Inoltre è necessario affrontare la problematica, instaurando nuovi processi capaci di indirizzare tutte le problematiche da gestire all’interno del processo di sviluppo del software.
Quali sono i temi principali che deve affrontare la PA?
Il primo problema che una PA deve affrontare riguarda la gestione dello sviluppo in outsourcing. È necessario normare il rapporto con gli outsourcer che sviluppano il progetto software per l’amministrazione. Un aspetto spesso sottovalutato è che si dà per scontato che gli aspetti di Security siano correttamente gestiti dal fornitore software senza neanche affrontare il problema.
E’ bene capire da subito che se il Committente non richiede la sicurezza, nessun Fornitore svilupperà “software sicuro”, in quanto ovviamente costa di più. La PA deve quindi rivedere le clausole contrattuali per includere gli aspetti di sicurezza. In generale i seguenti aspetti sono molto importanti:
- Indicare i requisiti di sicurezza del software, quali sono le caratteristiche di sicurezza del prodotto richiesto?
- Il fornitore dovrebbe indicare l’elenco delle architetture e del codice di terze parti utilizzato nel progetto: queste non devono essere causa di possibili vulnerabilità e dovrebbero essere oggetto di analisi da parte del Committente prima di approvare le scelte.
- Il diritto di rivedere il codice ed effettuare verifiche di sicurezza: in ogni fase dello sviluppo il Committente dovrebbe avere la possibilità di verificare il codice secondo tempi e modalità stabiliti.
- Nominare un responsabile della sicurezza applicativa del Fornitore necessario per la gestione di tutte le problematiche di sicurezza.
- Gli SLA per quanto riguarda il processo di fixing: ovvero una volta identificata la issue, quali sono i tempi massimi per implementare il rimedio più robusto?
- L’elenco dei test da effettuare al fine di valutare la sicurezza del software
- Il Fornitore dovrà fornire un “pacchetto di certificazione” costituito dalla documentazione relativa all’insieme di controlli di sicurezza implementati al fine di proteggere al meglio l’applicazione.
Il processo di fixing delle vulnerabilità è il passo più importante del processo di sicurezza del software. E’ necessario ripetere il test l’applicazione dopo un bug fixing o una nuova release, per essere sicuri che le correzioni siano le più robuste possibili. La maturità del processo di sviluppo del software non si misura in base al numero vulnerabilità che si individuano, ma ai tempi di risposta del processo di fixing delle vulnerabilità.