Ciclo di vita dello sviluppo della sicurezza (SDL)

Maggio 2022

Le vulnerabilità della sicurezza sono ampiamente riconosciute nel settore informatico e dai nostri clienti che hanno bisogno di garanzie sulla sicurezza dei prodotti che utilizzano. A questo scopo, NetApp ha sviluppato Secure Development Lifecycle (SDL), uno standard per lo sviluppo dei prodotti che valuta e gestisce le potenziali vulnerabilità.

La soluzione SDL di NetApp definisce un processo rigoroso basato su best practice e standard di settore che i team di prodotto possono seguire per valutare la sicurezza e pianificare il rilascio di un prodotto sicuro. Il processo inizia con la definizione dei primi piani per un prodotto, prima che sia stata scritta una singola riga di codice, e si estende fino al monitoraggio dei prodotti una volta rilasciati.

La soluzione SDL implementata da NetApp è un processo a 6 fasi sostenibile e ripetibile (illustrato nella figura in basso), rivolto ai team addetti alla realizzazione dei prodotti e servizi NetApp. Durante lo sviluppo di un prodotto, i team NetApp possono eseguire questa serie esplicita e predefinita di attività allo scopo di garantire che il prodotto sia affidabile e sicuro. Il processo SDL consente a NetApp di comprendere i rischi a cui sono sottoposti i prodotti, nonché valutare l'efficacia della conformità con il processo SDL completo per il team di prodotto.

Il gruppo di sicurezza del prodotto offre ai team di prodotto best practice da adottare per il ciclo SDL, nonché procedure a supporto ed esperienza in materia di sicurezza. I team di prodotto possono implementare i processi e le policy SDL per offrire prodotti sicuri. SDL richiede che tutte le vulnerabilità note, incluse quelle di componenti di terze parti, siano state risolte in modo appropriato.

Il processo NetApp SDL inizia con la creazione di una maggiore consapevolezza e di competenze in materia di sicurezza all'interno dei nostri team di prodotto attraverso attività di formazione e la designazione dei "campioni di sicurezza".

NetApp richiede formazione in materia di sicurezza per il personale coinvolto nella fornitura di prodotti. La formazione sulla sicurezza include la conoscenza di aspetti quali minacce attuali, tecniche di sviluppo sicuro, vulnerabilità e metodi per affrontare i problemi di sicurezza. La formazione è personalizzata in base al ruolo dei tirocinanti, ad esempio product manager, sviluppatore o responsabile QA, e ha lo scopo di sviluppare consapevolezza in materia di sicurezza dei prodotti e supporto per l'integrazione delle pratiche di sicurezza nei processi di lavoro.

NetApp richiede un aggiornamento annuale sulla sicurezza per comunicare i cambiamenti che interessano inevitabilmente la sicurezza dei prodotti. NetApp offre inoltre forum interni e accesso a eventi commerciali per aiutare i singoli a migliorare le proprie conoscenze in materia di sicurezza.

I "campioni di sicurezza" sono professionisti attenti alla sicurezza dei team di prodotto NetApp che promuovono le best practice per lo sviluppo sicuro e il processo SDL nella loro organizzazione, promuovendo al contempo l'adozione di misure e conoscenze in materia di sicurezza dei prodotti in generale. A ogni campione viene offerta una formazione approfondita e in particolare vengono presentate le best practice per la sicurezza, tra cui NetApp SDL. Sebbene l'obiettivo principale sia quello di incorporare la leadership nella sicurezza nei team di sviluppo, questi campioni fungono anche da punti di contatto chiave per il gruppo addetto alla sicurezza dei prodotti durante il monitoraggio del processo SDL da parte del team di prodotto.

Il processo NetApp SDL inizia con una valutazione della sicurezza e il rilascio dei piani di conformità e test. Procede quindi alla valutazione completa dei problemi di sicurezza del prodotto e delle relative soluzioni e alla verifica che le eventuali vulnerabilità identificate siano state risolte. Termina con la comunicazione dei rischi e l'attività di monitoraggio condotta da un Product Security Incident Response Team (PSIRT).

In questa fase del processo SDL è possibile distinguere tre punti di contatto: analisi della baseline di sicurezza del prodotto, modellazione e mitigazione delle minacce e analisi dell'ecosistema della catena di approvvigionamento. Tutti questi elementi vengono applicati nelle prime fasi dello sviluppo del progetto, prima di qualsiasi sviluppo o implementazione del codice.

Analisi della baseline di sicurezza del prodotto. La baseline di sicurezza del prodotto è un insieme minimo di livelli di sicurezza accettabili per tutti i prodotti NetApp. Viene ricavata dagli standard di sicurezza, come ISO/IEC 27001, e dagli impegni contrattuali assunti nei confronti dei clienti aziendali e governativi di NetApp. Il processo di revisione stabilisce una serie di passaggi che i team di prodotto possono seguire per valutare il proprio prodotto rispetto a ciascun requisito. Successivamente, i team definiscono un piano per aggiungere al prodotto eventuali funzionalità di base mancanti.

Modellazione e mitigazione delle minacce. La modellazione delle minacce viene utilizzata per identificare i difetti di sicurezza in una funzionalità, un componente o un prodotto sin dalle prime fasi del processo. Consente ai team di prodotto di considerare in modo strutturato le implicazioni per la sicurezza dei propri progetti. I team possono quindi identificare in modo più efficace le vulnerabilità della sicurezza, determinarne il rischio e sviluppare soluzioni adeguate. 

Trusted Supplier Program. L'obiettivo di questo programma è garantire che il nostro ecosistema di fornitori strategici sia in grado di garantire costantemente il massimo livello di sicurezza del settore. Grazie ad esso, NetApp valuta i fornitori strategici, sia nuovi che consolidati, che sono coinvolti nello sviluppo dei prodotti NetApp. L'audit aiuta i team di prodotto a verificare che le attività SDL siano incluse nei processi di sviluppo, produzione e supporto dei fornitori. Consente inoltre a NetApp di stabilire se i componenti in outsourcing rispettano i nostri standard.

In questa fase del processo SDL è possibile distinguere due punti di contatto: definizione dei piani per i test di conformità e di sicurezza.

Piano di conformità SDL. Attraverso il piano di conformità, i team di prodotto possono definire i livelli accettabili di sicurezza da implementare per una release specifica, nonché identificare in che modo saranno ritenuti responsabili per il rispetto di questi criteri. Definire questi livelli fin dall'inizio consente al team di comprendere i rischi associati ai problemi di sicurezza, identificare e correggere i difetti di sicurezza in fase di sviluppo e applicare gli standard SDL durante l'intero progetto.

Piano per il test di sicurezza. Il piano per il test di sicurezza integra i test case di sicurezza nella strategia di test e contempla i numerosi aspetti legati alla sicurezza, dall'autenticazione e l'autorizzazione alla protezione dei dati a riposo o in transito. La creazione e l'esecuzione di un piano per il test di sicurezza include la risoluzione dei problemi riscontrati, allo scopo di garantire che i potenziali problemi di sicurezza siano stati rilevati e risolti adeguatamente prima della release di un prodotto.

In questa fase del processo SDL è possibile distinguere sei punti di contatto: identificazione dei bug di sicurezza in una revisione del codice di sicurezza, test di sicurezza delle applicazioni statiche e dinamiche, ricerca di vulnerabilità note in fase di runtime, tra cui il fuzzing (test con dati casuali), e ricerca delle vulnerabilità nel software di terze parti.

Test di sicurezza delle applicazioni statiche. Prima della compilazione, i team di prodotto possono utilizzare questo test per eseguire la scansione del codice sorgente allo scopo di rilevare potenziali difetti critici, punti deboli nella sicurezza e vulnerabilità nel codice. Il test utilizza una serie di hook all'interno del processo di creazione di ciascun progetto e una serie di tool di reporting, come il tracciamento dei bug e la revisione del codice, per contrassegnare i difetti del prodotto. Gli sviluppatori sono responsabili del triaging e della risoluzione dei problemi identificati. In questo modo si evitano criticità nella release, quali problemi più seri di supportabilità, corruzione della memoria, errori gravi di sistema o persino esecuzione di codice in modalità remota.

Analisi del codice di sicurezza. L'analisi del codice di sicurezza è una tecnica per identificare i bug di sicurezza nelle prime fasi di sviluppo, prima dell'invio al controllo della versione. Permette di garantire che il codice non presenti punti deboli visibili per la sicurezza, come ad esempio schemi di codice specifici articolati nello standard Common Weakness Enumeration (CWE). La revisione del codice di sicurezza dipende dalle informazioni ottenute dal Test di sicurezza delle applicazioni statiche e dalla modellazione delle minacce.

Test di sicurezza delle applicazioni dinamiche. I team di prodotto possono identificare i problemi in fase di runtime eseguendo questo test su software completamente compilato, quindi testando la sicurezza del codice integrato e in esecuzione in un ambiente di test o di staging. L'attività di scansione prevede la configurazione dell'applicazione Web sottoposta a test per facilitare la scansione e quindi l'esecuzione dello strumento di scansione sull'applicazione. Queste scansioni possono portare alla luce un'ampia gamma di vulnerabilità, inclusi i problemi di convalida dell'input e dell'output che potrebbero rendere un'applicazione vulnerabile agli attacchi di tipo cross-site scripting o SQL injection. Possono inoltre aiutare a identificare gli errori di configurazione e altri problemi specifici delle applicazioni.

Scansione delle vulnerabilità. Per identificare le vulnerabilità della sicurezza comuni e note nei prodotti NetApp in fase di sviluppo, NetApp segue un processo standard utilizzando firme e controlli della configurazione. 

Fuzzing. Utilizzato per individuare le vulnerabilità della sicurezza, il fuzzing è una tecnica automatizzata di test di runtime che introduce dati non validi o solo parzialmente validi nelle interfacce del protocollo per identificare i risultati non desiderati. Lo strumento di fuzzing adottato dai team di prodotto NetApp supporta suite di test specifiche del protocollo che eseguono il fuzzing automatico in scatola nera. Questo test può identificare problemi come RFC non conformi. Il fuzzing è spesso associato al Test di sicurezza delle applicazioni dinamiche e fa parte degli sprint di sviluppo utilizzati durante il test del codice. 

Scansione del software di terze parti. La scansione del software di terze parti (o analisi della composizione del software) è utile per gestire i rischi per la sicurezza derivanti dall'utilizzo di componenti di terze parti. Permette di creare un inventario di software open-source e componenti di terze parti integrati nei nostri prodotti. La scansione può indicare quali componenti sono più esposti a problemi legali e di sicurezza, che potrebbero richiedere un'azione correttiva prima che il prodotto possa essere rilasciato. Questo permette di identificare rapidamente le vulnerabilità note e consente ai team di prodotto di creare un piano per affrontarle. La scansione può essere eseguita continuamente perché le nuove vulnerabilità rilevate possono essere segnalate in qualsiasi momento.

Dopo che i team di prodotto hanno identificato e risolto i problemi di sicurezza, possono procedere alla convalida delle correzioni implementate.

La comunicazione dei rischi nel processo SDL implica la valutazione, la comunicazione e la gestione dei rischi identificati nei punti di contatto precedenti del processo SDL. Può includere fasi quali test di penetrazione, reporting formale o sviluppo di procedure di risposta agli incidenti specifiche del prodotto.

Il Product Security Incident Response Team (PSIRT) è responsabile del coordinamento e della gestione delle indagini sulle vulnerabilità, segnalate pubblicamente o internamente all'azienda, e della risposta di NetApp, che include avvisi pubblici relativi alle indagini e alla mitigazione. I team di prodotto designano una persona di riferimento del proprio team che dovrà coordinarsi con il team PSIRT.