Controlli DevSecOps

DevSecOps applica la sicurezza dell'innovazione grazie all'integrazione di processi e strumenti di sicurezza nel processo di sviluppo DevOps.

Poiché la metodologia DevOps è una disciplina emergente con un elevato livello di variazioni dei processi, il successo delle procedure DevSecOps si basa sulla comprensione e sull'integrazione attenta della sicurezza nel processo di sviluppo. L'aggiunta della sicurezza deve iniziare con modifiche a poco invasive al codice, ai processi di sviluppo e all'infrastruttura che ospita il carico di lavoro. Concentrarsi prima di tutto sulle modifiche con l'effetto più positivo sulla sicurezza e che allo stesso tempo comportano un carico minimo sui processi e sulle competenze DevOps.

Questa documentazione esamina ogni fase di un processo DevOps di integrazione continua e recapito continuo (CI/CD) e i controlli di sicurezza che è consigliabile integrare per primi.

Pianificare e sviluppare

In genere, lo sviluppo moderno segue una metodologia di sviluppo Agile. Scrum è un'implementazione della metodologia Agile in cui ogni ciclo sprint inizia con un'attività di pianificazione. L'introduzione della sicurezza in questa parte del processo di sviluppo deve essere incentrata su:

• Modellazione delle minacce per visualizzare l'applicazione attraverso la lente di un potenziale utente malintenzionato
• Plug-in di sicurezza IDE e hook pre-commit per controlli di analisi statica leggeri all'interno di un ambiente di sviluppo integrato (IDE).
• Revisioni paritarie e standard di codifica sicura per identificare standard di codifica di sicurezza efficaci, processi di revisione paritaria e hook pre-commit.

Non è obbligatorio aggiungere tutti questi passaggi. Tuttavia, ogni passaggio consente di rivelare i problemi di sicurezza in anticipo, quando sono molto più economici e più facili da risolvere.

Modellazione delle minacce

La modellazione delle minacce è probabilmente la procedura di sicurezza più importante. Offre risultati immediati e contribuisce a sviluppare una mentalità incentrata sulla sicurezza che aiuta gli sviluppatori a migliorare la sicurezza in tutti i progetti futuri.

La modellazione delle minacce è un concetto semplice, anche se può essere dettagliato e tecnico, se necessario. La modellazione delle minacce rivela e documenta una vista realistica della sicurezza dell'applicazione, che include:

• Modalità con cui gli utenti malintenzionati possono usare in modo improprio la progettazione dell'applicazione
• Come risolvere le vulnerabilità
• Importanza della correzione dei problemi

La modellazione delle minacce consente di comprendere in modo efficace la mentalità di un utente malintenzionato. Consente di visualizzare l'applicazione dal punto di vista di un utente malintenzionato. Si apprenderà come bloccare i tentativi prima che gli utenti malintenzionati possano eseguire qualsiasi operazione. Se il team usa utenti tipo nella progettazione, è possibile trattare l'utente malintenzionato come un utente tipo ostile.

Esistono approcci pubblicati per la modellazione delle minacce che vanno da semplici metodi di domanda e risposta all'analisi dettagliata basata su strumenti. È possibile basare l'approccio su metodologie come il modello STRIDE o la modellazione delle minacce OWASP.

Modellazione delle minacce: semplice approccio iniziale

Poiché alcuni approcci alla modellazione delle minacce possono richiedere molto tempo e competenze, è consigliabile iniziare con un approccio più semplice usando domande di base. I metodi più semplici sono meno completi, ma consentono di avviare il processo di pensiero critico e di identificare rapidamente i principali problemi di sicurezza.

Vedere i metodi di domande semplici seguenti per iniziare:

• Metodo di domande semplici di Microsoft: questo metodo pone domande tecniche specifiche progettate per fare emergere gli errori comuni di progettazione della sicurezza.
• Modellazione delle minacce OWASP: questo metodo è incentrato su domande semplici e non tecniche per iniziare il processo di modellazione delle minacce.

È possibile usare uno o entrambi questi approcci, a seconda di ciò che si ritiene più appropriato per il team.

Quando il team gestisce il processo con maggiore sicurezza, può applicare tecniche più avanzate dal ciclo di vita di sviluppo della sicurezza Microsoft. Il team può anche integrare gli strumenti di modellazione delle minacce, ad esempio lo strumento di modellazione delle minacce Microsoft, per ottenere informazioni dettagliate migliori e contribuire all'automazione del processo.

Un'altra risorsa utile è A Guide to Threat Modelling for Developers (Guida alla modellazione delle minacce per sviluppatori).

Plug-in di sicurezza IDE e hook pre-commit

Gli sviluppatori si concentrano sulla velocità di consegna e i controlli di sicurezza possono rallentare il processo. In genere, il rallentamento si verifica se i controlli di sicurezza iniziano dalla pipeline. Uno sviluppatore individua la potenziale vulnerabilità dopo il push del codice nel repository. Per accelerare il processo e fornire un feedback immediato, è opportuno aggiungere passaggi come i plug-in di sicurezza IDE e gli hook pre-commit.

I plug-in di sicurezza dell'ambiente di sviluppo integrato identificano diversi problemi di sicurezza diversi durante il processo di sviluppo nell'ambiente di sviluppo integrato familiare dello sviluppatore. I plug-in possono fornire feedback immediato in caso di potenziali rischi di sicurezza nel codice scritto dello sviluppatore. I plug-in possono anche rivelare rischi nella libreria o nel pacchetto di terze parti. A seconda dell'IDE scelto, sono disponibili molti plug-in open source o commerciali e forniti dalle aziende di sicurezza.

Un'altra opzione da valutare consiste nell'usare un framework pre-commit se il sistema di controllo della versione lo consente. Un framework pre-commit fornisce script hook Git che consentono di identificare i problemi prima che uno sviluppatore invii il codice per la revisione. Un esempio è il pre-commit che è possibile configurare in GitHub.

Revisione paritaria e standard di codifica sicura

Le richieste pull sono elementi standard nel processo di sviluppo. Parte del processo di richiesta pull è l'esecuzione di revisioni paritarie che rileva spesso difetti, bug o problemi correlati a errori umani. È consigliabile che sia presente un membro del team responsabile della sicurezza o esperto di sicurezza che possa guidare lo sviluppatore durante il processo di revisione paritaria prima di creare una richiesta pull.

Le linee guida sulle procedure di codifica sicura consentono agli sviluppatori di apprendere i principi fondamentali per la scrittura di codice sicuro e le modalità di applicazione. Sono disponibili procedure di codifica sicura, come le procedure di codifica sicura OWASP, incorporate con le procedure di codifica generali.

Eseguire il commit del codice

In genere, gli sviluppatori creano, gestiscono e condividono il codice in repository, ad esempio GitHub o Azure Repos. Questo approccio offre una libreria centrale con controllo della versione del codice che può essere usata facilmente dagli sviluppatori per collaborare. Tuttavia, l'abilitazione di molti collaboratori in una singola codebase può anche comportare il rischio di introduzione di modifiche. Tale rischio può portare a vulnerabilità o può includere accidentalmente credenziali o token nei commit.

Per rispondere a questo rischio, i team di sviluppo devono valutare e implementare una funzionalità di analisi del repository. Gli strumenti di analisi del repository eseguono l'analisi del codice statico nel codice sorgente all'interno dei repository. Gli strumenti cercano vulnerabilità o modifiche alle credenziali e contrassegnano eventuali elementi trovati per la correzione. Questa funzionalità offre protezione dagli errori umani ed è utile per i team distribuiti in cui molte persone collaborano nello stesso repository.

Gestione delle dipendenze

Fino al 90% del codice nelle applicazioni correnti contiene elementi di o è basato su librerie e pacchetti esterni. Con l'adozione delle dipendenze nel codice sorgente, è essenziale affrontare i potenziali rischi. Molte librerie di terze parti presentano gravi problemi di sicurezza. Gli sviluppatori non seguono inoltre in modo coerente il ciclo di vita migliore e non mantengono aggiornate le dipendenze.

Assicurarsi che il team di sviluppo sappia quali componenti includere nelle applicazioni. È consigliabile scaricare versioni sicure e aggiornate da origini note. È inoltre consigliabile avere un processo per mantenere aggiornate le versioni. Il team può usare strumenti come il progetto Dependency-Check OWASP, WhiteSource e altri ancora.

Concentrarsi solo sulle vulnerabilità delle dipendenze o sul rispettivo ciclo di vita non è sufficiente. È anche importante risolvere i problemi di sicurezza dei feed dei pacchetti. Esistono vettori di attacco noti contro i sistemi di gestione dei pacchetti, come il typosquatting, la compromissione dei pacchetti esistenti, gli attacchi di sostituzione e altro ancora. Pertanto, l'amministrazione responsabile della gestione dei pacchetti deve affrontare questi rischi. Per altre informazioni, vedere Tre modi per mitigare il rischio quando si usano feed di pacchetti privati.

Test statici di sicurezza delle applicazioni

Dopo aver affrontato le librerie e la gestione dei pacchetti di terze parti, è essenziale che il team si concentri sul miglioramento della sicurezza del codice. Esistono diversi modi per migliorare la sicurezza del codice. È possibile usare plug-in di sicurezza dell'IDE. In alternativa, è possibile collegare controlli di pre-commit e commit incrementali di analisi statica come illustrato in precedenza. È anche possibile eseguire un'analisi completa del codice sorgente per individuare gli errori non rilevati dai passaggi precedenti. È necessario, ma è possibile che l'analisi di un grande blocco di codice richieda ore o addirittura giorni. Questo approccio può rallentare lo sviluppo e introdurre un carico di lavoro aggiuntivo.

Tuttavia, un team deve iniziare da qualche parte quando si implementano procedure di analisi del codice statico. Un approccio consiste nell'introdurre l'analisi del codice statico all'interno dell'integrazione continua. Questo metodo verifica la sicurezza non appena si verificano modifiche al codice. Un esempio è SonarCloud. Esegue il wrapping di più strumenti SAST (Static Application Security Testing) per diversi linguaggi. SonarCloud valuta e monitora il debito tecnico, con una particolare attenzione alla facilità di gestione. Esamina la qualità e lo stile del codice e include controlli specifici della sicurezza. Ma sul mercato sono disponibili molti altri strumenti commerciali e open source.

Per assicurarsi che il ciclo di feedback sia efficace, è essenziale ottimizzare lo strumento. Si vuole ridurre al minimo i falsi positivi e fornire feedback chiaro e gestibile sui problemi da risolvere. È anche utile implementare un flusso di lavoro, che impedisce il commit del codice nel ramo predefinito se vengono riscontrati problemi. È consigliabile includere sia i risultati qualitativi che di sicurezza. In questo modo, la sicurezza diventa parte dell'esperienza di unit test.

Proteggere le pipeline

DevOps offre un'automazione di livello superiore perché tutto il ciclo di vita dello sviluppo passa attraverso una pipeline. L'integrazione continua e il recapito continuo (CI/CD) sono una parte fondamentale dei cicli di sviluppo moderni. In CI/CD il team unisce il codice sviluppatore in una codebase centrale in base a una pianificazione regolare ed esegue automaticamente compilazioni e processi di test standard.

Le pipeline di infrastruttura sono una parte centrale dello sviluppo. L'uso di pipeline per eseguire script o distribuire codice in ambienti di produzione può tuttavia presentare problemi di sicurezza specifici. È consigliabile assicurarsi che le pipeline CI/CD non diventino mezzi per eseguire codice dannoso, consentire il furto delle credenziali o fornire agli utenti malintenzionati qualsiasi superficie di attacco per l'accesso. È inoltre consigliabile assicurarsi che venga quindi distribuito solo il codice che il team intende rilasciare.

I team DevOps devono assicurarsi di implementare i controlli di sicurezza adeguati per la pipeline. A seconda della piattaforma scelta, esistono diverse linee guida per gestire tali rischi. Per altre informazioni, vedere Protezione di Azure Pipelines.

Compilazione e test

Molte organizzazioni usano le pipeline di compilazione e versione per automatizzare e standardizzare i processi per la creazione e la distribuzione del codice. Le pipeline di versione consentono ai team di sviluppo di apportare modifiche iterative alle sezioni del codice rapidamente e su larga scala. I team non dovranno dedicare troppo tempo a ridistribuire o aggiornare gli ambienti esistenti.

L'uso delle pipeline di versione consente inoltre ai team di promuovere il codice dagli ambienti di sviluppo, tramite ambienti di test e infine nell'ambiente di produzione. Come parte dell'automazione, quando distribuiscono il codice negli ambienti di test i team di sviluppo devono includere strumenti di sicurezza che eseguono test automatizzati con script. I test devono includere unit test sulle funzionalità dell'applicazione per verificare le vulnerabilità o gli endpoint pubblici. Il test garantisce l'accesso intenzionale.

Test dinamici di sicurezza delle applicazioni

In un modello di sviluppo a cascata classico, la sicurezza veniva tradizionalmente introdotta nell'ultima fase, subito prima di andare in produzione. Uno degli approcci di sicurezza più diffusi è il test di penetrazione. I test di penetrazione consentono a un team di esaminare l'applicazione dal punto di vista della sicurezza "black box", ovvero più vicino alla mentalità di un utente malintenzionato.

Un test di penetrazione è costituito da diversi punti di azione, uno dei quali è noto come test dinamico di sicurezza delle applicazioni (DAST, Dynamic Application Security Testing). DAST è un test di sicurezza delle applicazioni Web che individua i problemi di sicurezza nell'applicazione in esecuzione, esaminando in che modo l'applicazione risponde a richieste preparate appositamente. Gli strumenti DAST sono noti anche come scanner di vulnerabilità delle applicazioni Web. Un esempio è uno strumento open source, OWASP Zed Attack Proxy (ZAP). Trova vulnerabilità nell'applicazione Web in esecuzione. OWASP ZAP esegue l'analisi in diversi modi: analisi baseline passiva o analisi completa, in base alla configurazione.

Lo svantaggio del test di penetrazione è che richiede molto tempo. Un test di penetrazione completo potrebbe richiedere fino a diverse settimane e, considerata la velocità dello sviluppo DevOps, tale intervallo di tempo potrebbe non essere sostenibile. È comunque utile aggiungere una versione più leggera del test di penetrazione durante il processo di sviluppo per individuare problemi non rilevati da SAST e altri passaggi. Gli strumenti DAST come OWASP ZAP possono risultare utili.

Gli sviluppatori integrano OWASP ZAP nella pipeline come attività. Durante l'esecuzione, lo scanner di OWASP ZAP si attiva nel contenitore e ne esegue l'analisi, quindi pubblica i risultati. Questo approccio potrebbe non essere perfetto, perché non è un test di penetrazione completo, ma è comunque utile. È una misura di controllo qualità aggiuntiva nel ciclo di sviluppo per migliorare la postura di sicurezza.

Convalida della configurazione cloud e analisi dell'infrastruttura

Oltre all'analisi e alla protezione del codice per le applicazioni, è necessario assicurarsi che anche gli ambienti in cui si distribuiscono le applicazioni siano sicuri. Gli ambienti sicuri sono essenziali per le organizzazioni che vogliono rimanere all'avanguardia, innovare e usare nuove tecnologie. Gli ambienti sicuri consentono ai team di creare rapidamente nuovi ambienti per la sperimentazione.

Le funzionalità di Azure consentono alle organizzazioni di creare standard di sicurezza da ambienti, ad esempio Criteri di Azure. I team possono usare Criteri di Azure per creare set di criteri. I set di criteri impediscono la creazione di determinati tipi di carichi di lavoro o elementi di configurazione, ad esempio indirizzi IP pubblici. Queste funzionalità di protezione consentono ai team di sperimentare in un ambiente sicuro e controllato, bilanciando innovazione e governance.

Uno dei modi in cui DevOps può contribuire all'allineamento tra sviluppatori e operazioni consiste nel supportare la conversione dell'infrastruttura esistente in un approccio di infrastruttura come codice.

L'infrastruttura come codice è la gestione di infrastruttura (reti, macchine virtuali, servizi di bilanciamento del carico e topologia di connessione) in un modello descrittivo. L'infrastruttura come codice usa lo stesso modello di controllo delle versioni usato dal team DevOps per il codice sorgente. Seguendo il principio per cui lo stesso codice sorgente genera lo stesso risultato binario, un modello di infrastruttura come codice genera lo stesso ambiente ogni volta che viene applicato. L'infrastruttura come codice è una procedura chiave di DevOps usata con la distribuzione continua.

DevSecOps rivoluziona la sicurezza e mostra che la sicurezza non riguarda solo la sicurezza delle applicazioni, ma anche la sicurezza dell'infrastruttura. Uno dei modi in cui DevSecOps supporta la sicurezza dell'infrastruttura consiste nell'includere l'analisi della sicurezza prima della distribuzione dell'infrastruttura nel cloud. Poiché l'infrastruttura è diventata codice, si applicano all'infrastruttura le stesse azioni di sicurezza adottate per la sicurezza dell'applicazione. Sono disponibili strumenti di sicurezza per eseguire l'analisi della sicurezza dell'infrastruttura in base alla strategia di infrastruttura come codice scelta.

Con l'adozione del cloud, la containerizzazione è un approccio comune adottato dai team nelle decisioni relative all'architettura delle applicazioni. Alcuni repository di contenitori analizzano le immagini per rilevare i pacchetti con vulnerabilità note. C'è comunque il rischio che un contenitore possa includere software non aggiornato. Considerando questo rischio, è fondamentale analizzare il contenitore per verificare la presenza di eventuali rischi per la sicurezza. Esistono molti strumenti di sicurezza open source e commerciali specifici per questa area, che supportano l'integrazione stretta nel processo di recapito continuo. Gli strumenti di sicurezza consentono ai team di adottare DevSecOps per l'infrastruttura come codice e in modo più specifico di apprendere come usare i contenitori.

Passare all'ambiente di produzione e operare

Quando la soluzione passa in produzione, è fondamentale continuare a supervisionare e gestire lo stato di sicurezza. In questa fase del processo è necessario concentrarsi sull'infrastruttura cloud e sull'applicazione complessiva.

Analisi della configurazione e dell'infrastruttura

Per ottenere visibilità per le sottoscrizioni cloud e la configurazione delle risorse in più sottoscrizioni, usare Azure Tenant Security Solution (AzTS) del team di AzSK.

Azure include funzionalità di monitoraggio e sicurezza. Queste funzionalità rilevano e generano avvisi per ogni evento anomalo o per configurazioni che richiedono indagini e potenziali correzioni. Tecnologie come Microsoft Defender per il cloud e Microsoft Sentinel sono strumenti proprietari che offrono integrazione nativa negli ambienti Azure. Queste tecnologie integrano gli strumenti di sicurezza dell'ambiente e del codice. E le tecnologie forniscono un monitoraggio completo della sicurezza, in modo che le organizzazioni possano sperimentare e innovare rapidamente e in modo sicuro.

Test di penetrazione

Il test di penetrazione è una procedura consigliata per verificare la presenza di eventuali vulnerabilità nella configurazione dell'infrastruttura o dell'applicazione che possono creare punti deboli che gli utenti malintenzionati potrebbero sfruttare.

Molti prodotti e partner offrono servizi di test di penetrazione. Microsoft fornisce indicazioni per i test di penetrazione in Azure.

In genere sono inclusi i tipi di test seguenti:

• Test sugli endpoint per individuare le vulnerabilità
• Test con dati casuali (ricerca di errori del programma fornendo dati di input in formato non valido) degli endpoint
• Port scanning degli endpoint

Informazioni di utilità pratica

Gli strumenti e le tecniche in queste indicazioni offrono un modello di sicurezza olistico per le organizzazioni che vogliono rimanere all'avanguardia e sperimentare nuove tecnologie che favoriscono l'innovazione. Un elemento chiave di DevSecOps è costituito dai processi basati sui dati e sugli eventi. Questi processi consentono ai team di identificare, valutare e rispondere ai potenziali rischi. Molte organizzazioni scelgono di integrare avvisi e dati di utilizzo nella piattaforma di Gestione dei servizi IT. Il team può quindi adottare lo stesso flusso di lavoro strutturato per gli eventi di sicurezza usati per altri eventi imprevisti e richieste.

Cicli di feedback

Tutti questi strumenti e tecniche consentono ai team di individuare e contrassegnare rischi e vulnerabilità che richiedono un'analisi e una potenziale risoluzione. I team operativi che ricevono un avviso o individuano un potenziale problema quando esaminano un ticket di supporto necessitano di un percorso per segnalare al team di sviluppo gli elementi da rivedere. Un ciclo di feedback semplice e collaborativo è fondamentale per risolvere rapidamente i problemi e ridurre il più possibile il rischio di vulnerabilità.

Un criterio comune per il feedback consiste nell'integrazione nel sistema di gestione del lavoro di uno sviluppatore, ad esempio Azure DevOps o GitHub. Un'organizzazione può collegare avvisi o eventi imprevisti agli elementi di lavoro per consentire agli sviluppatori di pianificare e intervenire. Questo processo offre agli sviluppatori un modo efficace per risolvere i problemi all'interno del flusso di lavoro standard, tra cui sviluppo, test e rilascio.