BlockChain: Cosa è e cosa non è
18 Gennaio 2018
Crisis Management – Gestione del rischio informatico e conseguente gestione della crisi
22 Gennaio 2018

Sviluppo sicuro delle applicazioni: il processo

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

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:

  • 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à.

Identificazione dei requisiti di sicurezza

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).

I test

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), 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 (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.

I passaggi di ambiente (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

Lavora dal 1999 nel campo della sicurezza delle informazioni, della qualità e della gestione dei servizi IT.

Ha condotto progetti di consulenza per la pubblica amministrazione e per il settore privato. Opera, sia in Italia che all’estero, come Lead Auditor ISO/IEC 27001, ISO 9001, ISO/IEC 200000 e ISO 22301. Ha progettato ed erogato corsi di Quality Assurance e di certificazione Lead Auditor ISO/IEC 27001 e ITIL Foundation.

Tra gli attestati si segnalano: le certificazioni AICQ SICEV Lead Auditor ISO/IEC 27001, IRCA Lead Auditor 9001, CISA, ITIL Expert e CBCI, la qualifica come Lead Auditor ISO/IEC 20000 e il perfezionamento postlaurea in “Computer Forensics e investigazioni digitali”.

E’ capodelegazione del WG1 del comitato italiano ISO/IEC SC27 in UNINFO.

Ha pubblicato il libro, aggiornato nel 2017, “Sicurezza delle informazioni: valutazione del rischio; i sistemi di gestione; la norma ISO/IEC 27001:2013”.

Cura la pubblicazione, dal 2008, della newsletter “IT Service management news” (http://www.cesaregallotti.it/Newsletter.html).

Web: www.cesaregallotti.it; Blog: blog.cesaregallotti.it

Download PDF
Condividi sui Social Network:

ISCRIVITI ALLA NEWSLETTER DI ICT SECURITY MAGAZINE

Una volta al mese riceverai gratuitamente la rassegna dei migliori articoli di ICT Security Magazine

Rispettiamo totalmente la tua privacy, non cederemo i tuoi dati a nessuno e, soprattutto, non ti invieremo spam o continue offerte, ma solo email di aggiornamento.
Privacy Policy