Sviluppo sicuro delle applicazioni: il processo

L’approfondimento sullo sviluppo dei sistemi informatici prosegue con il focus sulle pratiche essenziali per garantire lo sviluppo sicuro delle applicazioni e dei software, analizzando i modelli a cascata e Agile. Si evidenzia l’importanza della pianificazione accurata, dell’identificazione precoce dei requisiti di sicurezza, dell’esecuzione di test completi e della gestione rigorosa dei passaggi di ambiente tra sviluppo, test e produzione, per minimizzare le vulnerabilità e garantire un software sicuro e di alta qualità.

Lo sviluppo sicuro delle applicazioni e i modelli a cascata e Agile

Questo articolo prosegue la serie dedicata ai temi su cui ci sono i maggiori dubbi e perplessità sulle norme della serie ISO/IEC 27000.

Qui si prosegue a trattare lo sviluppo dei sistemi informatici, già introdotto dall’articolo “Sviluppo sicuro delle applicazioni: i requisiti”.

In questo articolo si tratta del processo di sviluppo, affrontando il modello “a cascata” e quello Agile. I punti chiave per la sicurezza durante lo sviluppo di sistemi informatici, approfonditi nei paragrafi successivi, sono:

• la pianificazione;
• l’identificazione dei requisiti funzionali, tecnici e di sviluppo e codifica;
• i test;
• i passaggi di ambiente (sviluppo, test e produzione).

Questo articolo non tratta tutte le fasi del ciclo di vita di un sistema informatico per concentrarsi solo su quelle sopra elencate.

Pianificazione per lo sviluppo sicuro delle applicazioni

La pianificazione deve essere tale da dare il tempo necessario a tutte le parti interessate di identificare e sviluppare i requisiti di sicurezza, realizzarli e verificarli.

Spesso i tempi delle verifiche (test) sono compressi per poter consegnare il sistema il prima possibile ai clienti. Questo ha conseguenze ben note, tra queste l’abbassamento del livello di qualità e sicurezza del sistema, aggravato, successivamente, da continue modifiche (spesso in emergenza).

Quando si pianificano i test è opportuno considerare non solo i tempi necessari per condurli, ma anche quelli per affrontare le carenze identificate e per verificare nuovamente il sistema dopo le correzioni.

Quando si adottano metodi di tipo Agile, la pianificazione è intrinseca nel metodo scelto (scrum, kanban o altro). È pertanto necessario che il metodo venga scelto e adottato con attenzione: troppo spesso, con la scusa che si lavora in modo Agile, sono omessi dei processi invece previsti dal metodo stesso (è bene ricordare che i metodi di tipo Agile hanno l’obiettivo di fornire software di alta qualità, e quindi le fasi di verifica e documentazione sono presenti).

Particolare attenzione, quando si adottano metodi di tipo Agile, va posta nella cosiddetta Definition of Done o DoD, ossia i criteri, stabiliti dagli sviluppatori, per determinare se un prodotto è finito. La DoD deve includere la buona riuscita dei test, inclusi quelli di sicurezza.

In fase di pianificazione (o, per chi adotta metodi di tipo Agile, nel corso dei primissimi sviluppi) vanno progettati (e poi realizzati) gli ambienti di sviluppo e test. Per essi vanno identificati i requisiti di sicurezza:

Identificazione dei requisiti di sicurezza nei progetti IT

• controllo accesso agli ambienti, limitandolo il più possibile;
• gestione delle versioni del software (inclusi script e schemi) sviluppato;
• backup di quanto sviluppato;
• logging delle modifiche e dei loro autori;
• aggiornamento degli strumenti di sviluppo (vulnerabilità identificate negli strumenti di sviluppo possono avere degli impatti sui sistemi prodotti);
• quali dati usare per i test (sicuramente non quelli di produzione e, per quanto possibile, neanche delle loro copie se i dati di produzione hanno caratteristiche di riservatezza);
• quali software di terze parti (inclusi quelli free, open source e le librerie) usare e come assicurarne l’aggiornamento in caso siano identificate vulnerabilità.

In un altro articolo (“Sviluppo sicuro delle applicazioni: i requisiti”, reperibile su https://www.ictsecuritymagazine.com/articoli/sviluppo-sicuro-delle-applicazioni-requisiti/), sono stati elencati alcuni requisiti da considerare quando si sviluppano sistemi informatici.

È necessario ricordare che i requisiti di sicurezza vanno identificati fin dalle prime fasi dello sviluppo e questo deve essere previsto in fase di pianificazione. È infatti noto che, se i requisiti di sicurezza sono identificati in un secondo tempo, la loro realizzazione ha maggiori carenze perché l’architettura adottata non è adeguata per supportarli o la loro integrazione con le parti del sistema già sviluppate presenta difficoltà.

Si ricorda che il principio sopra esposto è quello ben noto di security-by-design, poi adottato anche in ambito privacy e dal GDPR come privacy-by-design.

Nei metodi di tipo Agile, i requisiti di sicurezza vanno identificati sin dall’inizio nel backlog (come Storie o Epiche) in modo che l’assegnazione delle priorità di sviluppo li tenga sempre presenti.

I requisiti di codifica vanno invece inclusi nella DoD (un prodotto può essere considerato finito se il suo sviluppo ha adottato i requisiti di sicurezza nella fase di codifica).

Test di sicurezza e di funzionalità nel ciclo di vita del software

Sui test sarà dedicato un articolo successivo.

È qui opportuno ricordare che i test possono essere di molti tipi.

Ben noti sono i testi unitari (spesso svolti dagli sviluppatori stessi durante lo sviluppo sicuro delle app e dei software), di integrazione, di pre-produzione o staging. Questi test si concentrano soprattutto sulle funzionalità operative del sistema, non su quelle di sicurezza o sulla correttezza tecnica.

I test funzionali dovrebbero comunque includere le verifiche ai meccanismi di sicurezza, anche attraverso misuse case (un esempio molto semplice è la verifica del blocco dell’utenza dopo un certo numero di tentativi sbagliati di inserire la password).

La correttezza tecnica dal punto di vista della sicurezza può essere verificata in molti modi. Sono disponibili sul mercato (anche in versione free) molti software di verifica della qualità e sicurezza del codice e di scansione automatica delle vulnerabilità. Essi andrebbero adottati e il loro uso integrato nelle fasi di sviluppo sicuro delle app e dei software (chi adotta metodi di tipo Agile dovrebbe creare un ambiente di integrazione continua, in cui integrare tali prodotti).

I cosiddetti penetration test, condotti sui sistemi finiti in ambiente di produzione o pre-produzione, sono da considerarsi l’ultima delle tecniche di verifica della sicurezza di un sistema informatico. Infatti i problemi di sicurezza vanno identificati fin dall’inizio con l’identificazione dei requisiti e i misuse case e con test lungo tutto il ciclo di vita del sistema.

Gestione dei passaggi di ambiente tra sviluppo, test e produzione

I passaggi di ambiente vanno controllati, sottoponendoli ad autorizzazione. Le persone che possono autorizzare il passaggio non dovrebbero essere né gli stessi sviluppatori, né gli stessi addetti ai test, in modo da evitare conflitti di interesse (spesso gli errori non sono commessi volontariamente, ma perché le persone sono orientate a soddisfare i requisiti di costo e di tempo dei progetti, non quelli di sicurezza). Chi autorizza il passaggio di ambiente deve verificare che siano state condotte tutte le fasi di progettazione e test previste e che includano anche gli aspetti di sicurezza.

I metodi di tipo Agile non prevedono il ruolo di addetto ai test o di autorizzatore al passaggio di ambiente. Per questo deve essere ben definita la Definition of Done e ne deve essere verificata l’applicazione.

I passaggi di ambiente dovrebbero essere completamente automatizzati (gli sviluppatori dovrebbero quindi produrre opportuni script), in modo da ridurre al minimo l’errore umano in occasione dei passaggi in produzione.

Tutto il software (inclusi script e schemi) deve seguire il percorso previsto, dagli ambienti di sviluppo a quelli di produzione, anche in caso di emergenza. In altre parole, il software non deve mai essere modificato in ambiente di test o produzione, ma solo in quello di sviluppo. Questo perché, in caso contrario, gli sviluppatori si dimenticano spesso di riportare la modifica in ambiente di sviluppo. Questo ha come conseguenza che il successivo cambiamento, prodotto in ambiente di sviluppo, cancella quanto modificato nei soli ambienti di test o produzione e quindi le vulnerabilità non corrette in ambiente di sviluppo sono riportate nuovamente in ambiente di produzione.

A cura di: Cesare Gallotti