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:
Questo articolo non tratta tutte le fasi del ciclo di vita di un sistema informatico per concentrarsi solo su quelle sopra elencate.
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:
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).
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 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
Nel panorama odierno della sicurezza informatica, la protezione degli endpoint rappresenta un obiettivo imprescindibile per…
I numeri dell’evento Oltre 1000 ospiti, 42 relatori, 20 interventi tematici e 5 Tavole Rotonde:…
Group-IB è un fornitore, con sede a Singapore, di sistemi ad elevata attendibilità per il…
Le interazioni di natura digitale, su rete pubblica o all’interno di reti private, hanno assunto…
La Commissione Europea ha di recente ricordato come “Artificial intelligence (AI) is not science fiction;…
Di seguito il programma della Cyber Crime Conference 2024, che avrà luogo a Roma nei…