Controlli DevSecOps

  • Articolo

Questo articolo descrive come applicare i controlli di sicurezza per supportare le procedure di sicurezza SDL continue . Questi controlli di sicurezza sono parte integrante di una strategia DevSecOps che riguarda persone, processi e tecnologie. Questa documentazione descrive ogni controllo e illustra come applicare questi controlli a tre profili di sicurezza. Questi profili soddisfano i requisiti di sicurezza tipici per scenari aziendali comuni nella maggior parte delle organizzazioni:

Diagramma dei controlli di sicurezza rispetto al tempo e all'impatto.

Profili di controllo di sicurezza

In questo articolo sono disponibili tre livelli di profili di controllo a cui si fa riferimento.

Minimo temporaneo: profilo di sicurezza abbreviato per uno stato di eccezione temporaneo per supportare la creazione rapida di prototipi di carichi di lavoro a basso rischio. Questo profilo deve essere usato solo per le eccezioni temporanee che devono essere rilasciate in una sequenza temporale accelerata per soddisfare le esigenze aziendali critiche. Gli elementi che usano questo profilo devono essere rapidamente portati al profilo standard.

Approccio standard : bilanciato per la maggior parte dei carichi di lavoro, nella maggior parte dei casi.

Sicurezza elevata: sicurezza rigorosa per i carichi di lavoro con un potenziale impatto elevato sull'azienda e sulla sicurezza umana.

Controlli di sicurezza DevSecOps

Questa sezione fornisce un riferimento ai controlli di sicurezza consigliati per ogni tipo di carico di lavoro. Questo riferimento può essere adottato così come è o può essere adattato ai processi di sviluppo software e sicurezza software esistenti. La maggior parte delle organizzazioni non può implementare immediatamente tutti questi controlli se non ne stanno già eseguendo alcune. Adottare un approccio di miglioramento continuo è spesso l'approccio migliore: assegnare priorità ai controlli, implementare il primo controllo, passare al controllo successivo, implementarlo e così via. La maggior parte delle organizzazioni deve assegnare priorità prima alle basi critiche.

Per altre informazioni, vedere Il percorso di DevSecOps.

Questo diagramma riepiloga i controlli di sicurezza e come applicarli a ogni profilo di sicurezza del carico di lavoro.

Le considerazioni principali sulla pianificazione includono:

  • Spostamento a sinistra ma controllo doppio - Questo riferimento è progettato per rilevare e correggere i problemi il prima possibile per consentirti di risolverli quando è più semplice e conveniente risolvere i problemi (talvolta chiamati shift left), ma anche per presupporre errori e includere il controllo doppio più avanti nel processo. Controllare sempre tutti i controlli di sicurezza nel processo CI/CD, assicurarsi che i problemi evitabili non vengano passati ai sistemi di produzione. Questo concetto segue i principi "difesa avanzata" e "non sicuri".
  • Intelligenza artificiale : le due implicazioni principali dell'intelligenza artificiale sono:
    • Proteggere tutto il codice indipendentemente dal fatto che sia scritto dall'intelligenza artificiale umana o generativa
    • Usare entrambi per la sicurezza : applicare i controlli classici e di intelligenza artificiale disponibili per aumentare la visibilità e il contesto per eventuali problemi di sicurezza ( ad esempio gli strumenti di analisi del codice)

Controlli di sicurezza

I controlli vengono raggruppati nelle fasi di sviluppo a cui si applicano e i controlli comuni (basi critiche) che si applicano in tutte le fasi di sviluppo e i profili di controllo:

Ognuno di questi elementi è definito nelle sezioni seguenti:

Stabilire basi critiche

Questo controllo supporta la pratica CONTINUA SDL 1 - Stabilire standard di sicurezza, metriche e governance, Pratica 2 - Richiedere l'uso di funzionalità di sicurezza comprovate, linguaggi e framework e Pratica 10 - Fornire formazione sulla sicurezza.

Standard : questi controlli si applicano a tutte le fasi di sviluppo e i profili di controllo.

Formazione sulla sicurezza

Questo controllo è incentrato sulla fornitura di formazione agli sviluppatori e ai team di sicurezza per riconoscere e risolvere i problemi di sicurezza tramite il ciclo di vita dello sviluppo. Senza la formazione sulla sicurezza i team potrebbero perdere i punti deboli di sicurezza principali che portano a compromessi durante la durata delle applicazioni.

Di conseguenza, è fondamentale implementare la formazione sulla sicurezza in tutti i ruoli (inclusi utenti, sviluppatori, product line manager, tester e altro ancora). Ogni ruolo deve avere un'istruzione sui rischi per la sicurezza e il proprio ruolo per garantire la sicurezza delle applicazioni. Questa formazione può assumere la forma di: formazione formale o su richiesta, esercizi di simulazione, modellazione delle minacce, mentoring/advisor, promotori della sicurezza, team di supporto per la sicurezza delle applicazioni, attività del team viola, podcast, video o altri metodi di apprendimento.

In definitiva, ogni ruolo deve comprendere:

  • Perché è importante affrontare i rischi per la sicurezza
  • Cosa devono fare per la sicurezza nel loro ruolo
  • Come rendere la sicurezza parte del loro ruolo quotidiano

Persone chi comprende il punto di vista dell'utente malintenzionato, i relativi obiettivi e come si presenta in eventi imprevisti reali della sicurezza diventano rapidamente alleati per la sicurezza anziché tentare di evitare la sicurezza.

La sicurezza è un gioco senza fine in cui le minacce, la tecnologia e gli asset aziendali da proteggere cambiano sempre e gli attori delle minacce non rinunciano mai. L'approccio alla formazione sulla sicurezza deve essere continuo e in continua evoluzione. Una formazione efficace si allinea e rafforza i criteri di sicurezza, le procedure del ciclo di vita di sviluppo software (SDL), gli standard e i requisiti di sicurezza software. Il materiale di training deve provenire da informazioni dettagliate derivate dai dati e dalle nuove funzionalità tecniche disponibili.

Benché la sicurezza sia il compito di ognuno, è importante ricordare che non tutti devono essere esperti di sicurezza né tentare di diventare tester di penetrazione competenti. Assicurarsi che tutti comprendano le nozioni di base sulla sicurezza e come applicarle al proprio ruolo di creazione della sicurezza nel software e nei servizi è essenziale. Questo training deve includere l'uso sicuro di workstation, applicazioni, identità e account.

In particolare, gli sviluppatori e i tecnici che creano sistemi non sono in genere esperti di sicurezza. La formazione sia negli aspetti tecnici che concettuali della modellazione delle minacce è necessaria affinché diventino efficaci in modo da poter creare sistemi sicuri in base alla progettazione. Questo training è fondamentale per il processo di modellazione delle minacce per lavorare su larga scala nelle organizzazioni in cui gli sviluppatori superano notevolmente i professionisti della sicurezza. La modellazione delle minacce deve essere considerata come una competenza di ingegneria fondamentale in cui tutti gli sviluppatori e i tecnici devono avere almeno una competenza di base. Pertanto, i team di sviluppo e progettazione devono essere formati per essere competenti nella modellazione delle minacce come parte dell'onboarding e con aggiornamenti periodici.

Includere la sicurezza nei postmortemi senza colpa

L'analisi postmortem senza colpa è un metodo fondamentale per consentire ai team di imparare dagli errori in modo efficace ed efficiente senza attivare la difesa da parte dei membri del team cercando qualcuno di incolpare. Gli apprendimento sulla sicurezza devono essere inclusi in modo esplicito nel processo postmortem senza colpa per garantire che i team massimizzino anche gli apprendimento per la sicurezza.

Stabilire standard di sicurezza, metriche e governance

Le organizzazioni devono stabilire questi standard di sicurezza, metriche e governance perché sono alla base della capacità di innovare. Consente un programma di sicurezza sicuro che non solo protegge gli asset dell'organizzazione, ma si allinea anche agli obiettivi aziendali. Gli standard di sicurezza sono i requisiti di base e le procedure consigliate per garantire la sicurezza dei sistemi, dei dati e dei processi di un'organizzazione.

Questi standard devono essere misurati e regolamentati, tra cui il monitoraggio della conformità e la revisione e l'aggiornamento periodico per minacce, strumenti e altri fattori correnti. Questo processo deve coprire l'intero ciclo di vita dall'ideazione iniziale tramite la rimozione delle autorizzazioni dell'applicazione e degli ambienti di sviluppo di supporto.

Le metriche sono misurazioni usate per vedere quanto siano efficaci i controlli e i processi di sicurezza. Una metrica chiave è il tempo medio di correzione (MTTR) per tenere traccia del tempo per cui un'applicazione rimane vulnerabile. Questa misura ci permette di investire in modo strategico nelle correzioni di sicurezza emittente più tempestivamente.

Nota

Questo concetto è diverso da MTTR nelle operazioni di sicurezza incentrate sul tempo per rimuovere l'accesso antagonista alle risorse dell'organizzazione.

La governance della sicurezza funge da guida per i team di sicurezza ed è spesso basata su framework e processi usati da organizzazioni per gestire e controllare la sicurezza delle informazioni. Questi includono criteri, procedure, controlli e gestione dei rischi. Le metriche consentono di quantificare l'esposizione ai rischi. Senza di essi, l'organizzazione potrebbe non comprendere completamente le sue vulnerabilità e il potenziale impatto.

Poiché i requisiti di sicurezza potrebbero essere nuovi, è possibile adottare un approccio progressivo che aumenta gradualmente gli standard di codifica allo stato ideale. Questo approccio offre ai team il tempo necessario per apprendere e automatizzare il monitoraggio e i controlli.

Richiedere l'uso di funzionalità, linguaggi e framework di sicurezza comprovati

Definire e pubblicare un elenco di strumenti approvati e i relativi controlli di sicurezza associati. L'uso di soluzioni di sicurezza consolidate e comprovate è importante per evitare errori comuni perché la creazione di soluzioni sicure è molto complessa. Il tentativo di reinventare le soluzioni di sicurezza comporta quasi sempre un aumento del rischio per la sicurezza e il tempo e il lavoro richiesto.

Assicurarsi che gli sviluppatori e i tecnici sfruttano le nuove funzionalità di analisi della sicurezza e le nuove protezioni. Devono usare sempre il compilatore, il linker, le librerie e i flag del compilatore e del linker appropriati per generare file eseguibili sicuri.

Le organizzazioni devono implementare un processo di revisione e approvazione per convalidare la sicurezza di tutti i componenti integrati. Devono stabilire un criterio per usare solo i componenti approvati nei processi di compilazione e distribuzione applicati e monitorati.

Sicurezza delle identità di base

Assicurarsi che l'uso e l'integrazione dell'identità seguano procedure consigliate per la sicurezza ben consolidate. Gli attori delle minacce usano spesso tecniche di attacco alle identità nei sistemi di produzione e nei processi di sviluppo. Un detto popolare cattura questo, "gli utenti malintenzionati non si rompono, si limitano ad accedere".

La sicurezza delle identità assume due forme per lo sviluppo:

  • Identity Security for Development Process : assicurarsi che tutti i partecipanti al processo di sviluppo usino metodi di autenticazione avanzata per il lavoro quotidiano e abbiano solo i privilegi necessari per eseguire le attività di lavoro. Per altre informazioni, vedere la sezione Controlli di accesso alle identità o alle applicazioni.
  • Sicurezza delle identità per sistemi e applicazioni: assicurarsi che i sistemi che progettano e costruiscano seguano le procedure consigliate per i metodi di autenticazione e autorizzazione (e non creano le proprie imitazioni deboli di sistemi di identità comprovati e gestiti).

Applicare la sicurezza delle identità per sistemi e applicazioni seguendo le indicazioni riportate in queste risorse:

Standard crittografici

Applicare procedure di crittografia valide a tutti gli utilizzi della crittografia. Seguire tutte le linee guida descritte in Continuous SDL Practice 4 – Define and Use cryptographic Standards (Procedura continua SDL 4 - Definire e usare gli standard di crittografia).

Per altre informazioni, vedere Raccomandazioni di crittografia Microsoft SDL.

Protezione dell'ambiente di sviluppo

Questo controllo supporta la pratica CONTINUA SDL 6 - Protezione dell'ambiente di progettazione.

Questo controllo è incentrato sulla protezione dell'ambiente di sviluppo usando workstation sicure e ambienti di sviluppo integrato (IDE). Questo controllo evidenzia il vantaggio dell'uso di un approccio Zero Trust nel ciclo di vita dello sviluppo software.

Nel panorama attuale, gli utenti malintenzionati espandono le loro operazioni per indirizzare i computer degli sviluppatori e manomettere i processi di compilazione. Un esempio fondamentale di questo attacco è stato quello riscontrato da SolarWinds, in cui l'utente malintenzionato ha inserito una DLL dannosa prima delle fasi finali della compilazione software. In effetti, l'applicazione è stata backdoor e ha causato un attacco mirato distribuito a migliaia di clienti in tutto il mondo tramite la supply chain. Per altre informazioni sull'attacco SolarWinds, vedere il blog Microsoft Analisi di Solorigate, il file DLL compromesso che ha avviato un attacco informatico sofisticato e il modo in cui Microsoft Defender aiuta a proteggere i clienti.

È essenziale rafforzare le workstation, creare ambienti, identità e altri sistemi di sviluppo per garantire l'integrità delle applicazioni sviluppate. In caso contrario, crea un percorso per consentire agli utenti malintenzionati di compromettere l'applicazione tramite il sistema SCM (Source Code Management) o tramite la workstation per sviluppatori.

Questa procedura è una base fondamentale del ciclo di vita di sviluppo e deve essere stabilita su tutti i profili.

In questa pratica, è necessario adottare un approccio Zero Trust. Al suo interno il modello Zero Trust richiede che ogni richiesta di accesso (utente, servizio o dispositivo) venga verificata come se provenga da una rete non attendibile, indipendentemente dalla provenienza della richiesta o dalla risorsa a cui accede. Basare questo criterio di autenticazione e autorizzazione sempre su tutti i punti dati disponibili. È consigliabile limitare l'accesso degli utenti, in particolare gli utenti con privilegi, tramite i criteri JUST-In-Time e Just-Enough-Access (JIT/JEA) e segmentare l'accesso per ridurre al minimo i possibili danni in caso di violazione.

La protezione avanzata dell'ambiente di sviluppo può essere ottenuta tramite vari metodi, ma un buon punto di partenza è considerare la workstation per sviluppatori. Usando tecnologie come GitHub Codespaces o Microsoft DevBox, si sposta l'ambiente di sviluppo in applicazioni SaaS, che possono quindi essere gestite tramite impostazioni di sicurezza e di rete o tramite criteri dell'organizzazione.

Per bloccare ulteriormente le workstation per sviluppatori, è possibile rilasciarle workstation con accesso con privilegi/workstation di accesso sicuro (PAW/SAW). Queste workstation consentono di ridurre i vettori di minaccia e garantire un dispositivo per sviluppatori standardizzato e controllato.

Progettazione sicura

Eseguire la modellazione delle minacce (revisione della progettazione della sicurezza)

Questo controllo supporta la pratica SDL continua 3 - Eseguire la modellazione delle minacce.

Questo controllo identifica i punti deboli della sicurezza nella progettazione che possono causare incidenti di sicurezza e danni aziendali. I punti deboli della sicurezza nella progettazione possono essere difficili da attenuare dopo l'implementazione della progettazione, quindi trovare e correggere questi punti deboli all'inizio del ciclo di vita è fondamentale.

La modellazione delle minacce funge da processo di revisione della progettazione della sicurezza, che integra la sicurezza nella progettazione di un sistema o di un'applicazione.

La modellazione delle minacce identifica, valuta, assegna priorità e attenua i rischi per la sicurezza all'interno di un sistema software. Questo approccio strutturato per analizzare la progettazione e l'architettura di un'applicazione software identifica potenziali minacce e vulnerabilità nelle prime fasi del processo di sviluppo.

L'obiettivo finale è comprendere il sistema e cosa potrebbe andare storto. La modellazione delle minacce consente di raggiungere tale obiettivo applicando una conoscenza approfondita del sistema stesso e del modo in cui un potenziale utente malintenzionato lo visualizza.

Questo processo si svolge in genere sotto forma di workshop di individuazione delle minacce in cui un team di esperti del sistema e degli esperti della sicurezza collaborano per individuare e documentare i rischi. Anche se questo processo potrebbe iniziare in modo informale, dovrebbe evolversi rapidamente in un processo strutturato che illustra ogni aspetto del servizio in fase di compilazione, il modo in cui viene usato e le interfacce di sistema.

Le fasi della modellazione delle minacce sono:

  1. Identificare casi d'uso, scenari e asset : iniziare a comprendere quali funzioni aziendali e casi d'uso il sistema consente di valutare il potenziale impatto aziendale di qualsiasi compromissione del sistema e informare le discussioni da seguire.
  2. Creare una panoramica dell'architettura: creare un riepilogo visivo dell'applicazione (o usarne uno esistente) per comprendere chiaramente il sistema e il relativo funzionamento. Questa panoramica deve includere: una mappa dei processi aziendali, componenti e sottosistemi, limiti di attendibilità, meccanismi di autenticazione e autorizzazione, interfacce esterne e interne e flussi di dati tra attori e componenti.
  3. Identificare le minacce: usare una metodologia comune per enumerare potenziali minacce alla sicurezza, ad esempio il modello STRIDE o la modellazione delle minacce OWASP.
  4. Identificare e tenere traccia delle mitigazioni : monitorare e tenere traccia dei difetti di progettazione individuati usando i processi e gli strumenti di sviluppo esistenti per assicurarsi che le correzioni vengano implementate e documentate. Questo processo deve includere, assegnando priorità alle mitigazioni da eseguire per prime, in modo che i team passino il loro tempo prima sugli sforzi più importanti.This process should include, prioritizing which mitigations to do first so that teams spend their time on the most important efforts first. Questo processo è basato sui rischi e potrebbe non avere risorse per attenuare completamente tutti i rischi nel primo ciclo. Valutare attentamente quali mitigazioni, incluse le mitigazioni parziali, aumentano il costo per un utente malintenzionato per il costo e le risorse meno difensivi. L'obiettivo della sicurezza è l'errore dell'utente malintenzionato, che può assumere la forma di blocco completo di una tecnica di attacco, rilevandoli per abilitare una risposta del difensore, rallentandoli per dare ai difensori il tempo di risposta, limitando l'ambito dei danni e altro ancora.

Un modello di minaccia spesso funge da processo di istruzione per tutti i partecipanti, oltre a fornire un contesto importante per altre attività di pianificazione, implementazione e test della sicurezza.

Le applicazioni che includono l'uso di componenti di intelligenza artificiale devono valutare i tipi di rischio specifici associati all'intelligenza artificiale, che sono diversi dalle applicazioni classiche.

Creare e analizzare i modelli di minaccia comunicando sulla progettazione della sicurezza dei propri sistemi, analizzando tali progettazioni per potenziali problemi di sicurezza usando una metodologia comprovata e suggerendo e gestendo le mitigazioni per i problemi di sicurezza.

Proteggere il codice

Analisi codice

Questo controllo supporta la procedura SDL continua 7 - Eseguire test di sicurezza.

Questo controllo è incentrato sull'aumento della sicurezza del codice durante la scrittura/immissione del codice in un ambiente di sviluppo integrato (IDE) o durante l'archiviazione del codice. Questo controllo è l'elemento fondamentale delle procedure DevSecOps perché risolve direttamente le vulnerabilità che gli utenti malintenzionati sfruttano regolarmente.

Senza questo controllo, potrebbero mancare vulnerabilità codificate direttamente nell'applicazione dagli sviluppatori. Gli sviluppatori non sono dannosi, ma potrebbero non avere la competenza necessaria per identificare il motivo per cui hanno codificato non è sicuro.

Questo controllo è fondamentale per ottenere i vantaggi della produttività e della sicurezza di un approccio di spostamento a sinistra integrando gli strumenti direttamente nell'IDE. Questo processo consente l'individuazione rapida e la correzione delle vulnerabilità nelle prime e più convenienti opportunità. Questo processo può essere applicato retroattivamente alle applicazioni già sviluppate identificando i punti deboli della sicurezza e correggendoli in un secondo momento (anche se a spese e difficoltà maggiori).

Questo processo in genere assume la forma di plug-in IDE o strumenti di analisi dedicati che analizzano il codice usando i set di strumenti DAST (Static Analysis Security Testing) e Dynamic Analysis Security Testing (DAST).

Gli strumenti SAST analizzano la codebase esistente e hanno accesso completo al codice. Gli strumenti SAST possono identificare i punti deboli principali nel codice stesso. DAST viene invece eseguito nell'applicazione distribuita. Di conseguenza, non ha accesso al codice e viene eseguito per simulare e identificare i punti deboli della sicurezza in fase di esecuzione.

Nota

Le applicazioni di intelligenza artificiale hanno diversi tipi di vulnerabilità (come distorsioni e allucinazioni) rispetto alle applicazioni classiche e richiedono strumenti che si concentrano su tali vulnerabilità.

Il controllo qualità è importante! Una considerazione fondamentale per l'esecuzione di questi strumenti consiste nel garantire che vengano ottimizzati per ridurre il rumore e lo sforzo sprecato dai falsi positivi. L'ottimizzazione di questi strumenti richiede in genere un professionista della sicurezza con un background per sviluppatori che comprenda i processi di sviluppo dell'organizzazione. Gli stessi professionisti possono anche fornire indicazioni e competenze di valutazione sui singoli rilevamenti per gli sviluppatori. Possono aiutare a distinguere veri e falsi positivi, problemi reali e falsi allarmi. I processi per consentire agli sviluppatori di accedere a questi esperti sono spesso strettamente correlati all'offerta di formazione sulla sicurezza, ad esempio attraverso programmi promotori, team di supporto per la sicurezza delle applicazioni e così via.

Minimo temporaneo: assicurarsi di abilitare le funzionalità di sicurezza IDE predefinite e implementare un livello minimo di analisi SAST nel repository per identificare le vulnerabilità nell'applicazione. È necessario un processo documentato per correggere i problemi individuati in un tempo ragionevole, anche se lo standard "barra dei bug" dei quali i difetti devono essere risolti è limitato fino a quando l'applicazione non raggiunge i profili di sicurezza standard bilanciati o elevati.

Standard : assicurarsi di analizzare completamente tutti i componenti con tutti gli strumenti SAST/DAST applicabili e identificare i punti deboli. Verificare la copertura completa della sicurezza sul codice dell'applicazione. Assicurarsi di seguire il processo documentato per la correzione e avere uno standard "barra dei bug" che corrisponda alla tolleranza di rischio dell'organizzazione.

Sicurezza elevata: assicurarsi che tutte le applicazioni applicabili applichino un processo dettagliato e documentato per risolvere tutte le vulnerabilità di sicurezza. Applicare le correzioni prima di qualsiasi attività di compilazione o rilascio. Assicurarsi di seguire il processo documentato per la correzione e avere una "barra dei bug" estremamente restrittiva che corrisponda alla tolleranza di rischio dell'organizzazione per carichi di lavoro aziendali critici per la sicurezza elevata.

Sono disponibili molti strumenti da usare per l'analisi statica. Per altre informazioni, vedere l'elenco all'indirizzo Ciclo di vita di sviluppo della sicurezza Microsoft.

Proteggere la pipeline CI/CD

Supply chain/gestione delle dipendenze

Questo controllo supporta la procedura SDL continua 5 - Protezione della catena di approvvigionamento software.

Questo controllo è incentrato sulla protezione della supply chain di sviluppo usando strumenti e framework di analisi della composizione software, ad esempio Secure Supply Chain Consumption Framework (S2C2F). Questi processi consentono di ridurre il rischio di compromissione da parte di codice non Microsoft.

Nel panorama attuale, la maggior parte delle applicazioni si basa su software open source (OSS) con poca supervisione o controllo da parte dei consumer di questi componenti. Questo controllo evidenzia strategie, tecniche e tecnologie di base per inserire, usare, usare e gestire in modo sicuro il sistema operativo. Sottolinea anche la protezione delle dipendenze interne, garantendo un ciclo di vita end-to-end completo, indipendentemente dal codice del software.

Il mancato controllo della supply chain del software espone a vulnerabilità significative introdotte dal codice che non si controlla. Un esempio noto è la vulnerabilità log4J/Log4Shell, che ha consentito l'esecuzione di codice remoto in qualsiasi sistema o applicazione usando questo pacchetto. Tali vulnerabilità possono verificarsi accidentalmente o dannosamente.

La protezione della supply chain è una parte essenziale di garantire un ciclo di vita di sviluppo sicuro e deve essere considerata in ogni stato del profilo, anche se ogni singolo stato deve seguire lo stesso processo standardizzato di inserimento delle dipendenze.

Minimo temporaneo: inventariare tutte le dipendenze in modo da comprendere l'impatto di una vulnerabilità oss nell'applicazione. Questo inventario può essere ottenuto usando Dependabot o altri strumenti sca (Software Composition Analysis). Questi strumenti possono anche aiutare a generare una fattura software di materiali (SBOM).

Standard : analizzare tutte le vulnerabilità del sistema operativo e correggerle automaticamente con richieste pull automatiche. Questo controllo può essere ottenuto anche usando Dependabot e gitHub Dependency graph/review.

Sicurezza elevata: blocca attivamente tutti i pacchetti non sicuri con vulnerabilità sfruttabili usate nell'applicazione.

Per altre informazioni su questo controllo e misurare la maturità di OSS Security, vedere la documentazione sulle procedure consigliate di OSS Supply Chain Framework e GitHub su Protezione del ciclo di vita di sviluppo.

Revisione del codice di sicurezza

Questo controllo è incentrato sulla presenza di un codice di revisione esperto di sicurezza per identificare potenziali difetti di sicurezza. In questo modo è possibile trovare problemi di sicurezza difficili da automatizzare i rilevamenti.

Questa revisione può essere eseguita da: un peer dello stesso team con competenze di sicurezza delle applicazioni, un campione di sicurezza all'interno dell'organizzazione, un esperto di sicurezza delle applicazioni del team centrale di sicurezza delle app o un'entità esterna.

Questa recensione deve essere sempre una persona separata dallo sviluppatore che ha scritto il codice. Questa revisione deve essere eseguita come attività separata dopo il completamento dell'analisi automatica del codice.

Minimo temporaneo: questo controllo è consigliato per questo profilo.

Standard : questo controllo è consigliato per questo profilo.

Sicurezza elevata: questo controllo è necessario per tutte le applicazioni ad alta sicurezza e spesso coinvolge più esperti singoli.

Analisi delle credenziali e dei segreti

Questo controllo supporta la procedura SDL continua 7 - Eseguire test di sicurezza.

Questo controllo è incentrato sulla riduzione dei rischi derivanti dalle chiavi di autenticazione e da altri segreti esposti nel codice. Gli attori delle minacce hanno competenze e automazione per trovare e sfruttare segreti incorporati nel codice.

L'approccio migliore consiste nell'usare identità gestite e protocolli di autenticazione moderni anziché chiavi e segreti, quando possibile. Sebbene l'uso di chiavi API e segreti sia tradizionalmente una pratica di codifica e test, il metodo preferito deve essere sempre l'autenticazione basata sull'identità alle risorse a causa delle maggiori capacità di sicurezza e gestione del ciclo di vita. L'implementazione di questo controllo assume la forma dell'uso di identità gestite, ad esempio identità gestite per le risorse di Azure.

Se è necessario usare i segreti, è necessario proteggerli nell'intero ciclo di vita, inclusi la creazione, l'uso, la rotazione regolare e la revoca. Evitare di usare direttamente i segreti nel codice e archiviarli solo in un sistema di archiviazione sicuro di chiavi/segreti, ad esempio Azure Key Vault o un modulo di protezione hardware , se necessario. In nessun caso, le chiavi di testo normale e i segreti vengono mai archiviati nel codice, anche temporaneamente. Gli utenti malintenzionati troveranno e sfruttano questi segreti.

Importante

I repository di codice sorgente interno non sono sicuri.

I repository interni devono essere soggetti agli stessi requisiti dei repository esposti pubblicamente come gli attori delle minacce cercano spesso segreti e chiavi nei repository dopo aver ottenuto l'accesso a un ambiente tramite phishing o altri mezzi. Questa operazione è necessaria per un approccio Zero Trust che presuppone violazioni e progetta i controlli di sicurezza di conseguenza.

Standard - Una buona igiene segreta è essenziale ed è necessaria in tutti i profili.

Nota

Poiché questi segreti vengono trovati dai team o dagli utenti malintenzionati, è necessario assicurarsi che la chiave non possa essere usata per accedere alle risorse (varia in base al tipo di risorsa) oltre a modificare il meccanismo in un metodo di accesso più sicuro come le identità gestite.

Altri dettagli e risorse includono:

Nota

È consigliabile usare le chiavi per carico di lavoro con soluzioni di archiviazione segrete come Azure Key Vault.

Proteggere la pipeline

Questo controllo supporta la procedura SDL continua 5 - Protezione della catena di approvvigionamento software.

Questo controllo è incentrato sulla protezione della pipeline DevOps e di tutti gli artefatti creati durante i processi di compilazione dell'applicazione.

Le pipeline sono una parte essenziale dell'automazione delle attività ripetibili di base all'interno del ciclo di vita devSecOps. In CI/CD il team unisce il codice dello sviluppatore in una codebase centrale in base a una pianificazione regolare ed esegue automaticamente compilazioni e processi di test standard, inclusi i set di strumenti di sicurezza.

L'uso di pipeline per eseguire script o distribuire codice in ambienti di produzione può presentare problemi di sicurezza univoci. Assicurarsi che le pipeline CI/CD non diventino vie per eseguire codice dannoso, consentire il furto delle credenziali o concedere agli utenti malintenzionati qualsiasi area di attacco per l'accesso. È anche necessario assicurarsi che venga distribuito solo il codice che il team intende rilasciare. Questo processo include gli artefatti delle pipeline CI/CD, in particolare gli artefatti condivisi tra attività diverse che possono essere usate come parte di un attacco.

La generazione di materiali (SBOM) software deve essere automatizzata nel processo di compilazione per creare questo artefatto di verifica del codice fondamentalemente importante senza richiedere azioni manuali per sviluppatori.

La sicurezza della pipeline può essere garantita assicurando un buon controllo di accesso alle risorse usate nella pipeline e convalidando/aggiornando regolarmente dipendenze/script di base. È importante notare che gli script usati nelle pipeline CI/CD sono anche codice e devono essere trattati nello stesso modo in cui si tratta altro codice nel progetto.

Nota

La sicurezza della pipeline dipende dalla sicurezza dell'infrastruttura sottostante e dagli account/identità usati per il processo. Per altre informazioni, vedere la protezione dell'ambiente di sviluppo e i controlli delle operazioni sicure (Identità identità/Controllo di accesso app, controlli host/contenitori, Controllo di accesso di rete)

Standard : questo controllo deve essere valutato in base a un livello di accesso a ogni risorsa del progetto. Si tratta di un controllo obbligatorio in tutti i livelli di profilo DevSecOps.

Per altre informazioni sulla sicurezza della pipeline, vedere Protezione di Azure Pipelines.

Operazioni sicure

Test di penetrazione del sito live

Questo controllo supporta la procedura SDL continua 7 - Eseguire test di sicurezza.

I tester di penetrazione delle applicazioni professionali tentano di compromettere un'istanza dinamica del carico di lavoro completo. Questo test verifica che i controlli di sicurezza del carico di lavoro siano efficaci e coerenti. I test di penetrazione consentono di individuare ed evidenziare il percorso meno resistente che un utente malintenzionato potrebbe usare per sfruttare l'applicazione e compromettere l'azienda. I test di penetrazione possono essere incredibilmente preziosi quando eseguiti al momento giusto. Usarli dopo aver mitigato le vulnerabilità a basso costo e facili da sfruttare rilevate nelle analisi precedenti.

È consigliabile eseguire questo test a tutti i livelli dei profili di sicurezza DevSecOps.

Minimo temporaneo: è consigliabile eseguire un test di penetrazione in tutte le applicazioni. A causa dei vincoli di tempo, potrebbe essere possibile identificare solo metodi più semplici nell'applicazione che un utente malintenzionato potrebbe sfruttare. Pianificare rapidamente l'aggiornamento al livello standard almeno.

Standard : in un profilo standard è consigliabile eseguire un test di penetrazione. In questo caso, è possibile individuare vulnerabilità più complesse a causa dell'attenzione aggiuntiva eseguita all'inizio del processo di sviluppo.

Sicurezza elevata: per le applicazioni line-of-business e i carichi di lavoro critici, è necessario completare un test di penetrazione. Qualsiasi vulnerabilità in queste applicazioni deve essere trattata con maggiore attenzione e attenzione.

Integrare i risultati e il feedback di queste attività per migliorare i processi e gli strumenti di sicurezza.

Controlli di accesso alle identità e alle applicazioni

Questo controllo supporta la pratica SDL continua 8 - Garantire la sicurezza della piattaforma operativa e la pratica 6 - Proteggere l'ambiente di progettazione.

Assicurarsi che le procedure consigliate per la sicurezza per la gestione delle identità e degli accessi, inclusa la protezione dell'accesso con privilegi, siano seguite per tutti gli elementi tecnici dell'ambiente di sviluppo, la pipeline CI/CD, il carico di lavoro operativo e altri sistemi di sviluppo. Gli attori delle minacce hanno metodi sofisticati e automazione per gli attacchi di identità che usano frequentemente sia nei sistemi di produzione che nei processi di sviluppo. La gestione delle identità e degli accessi è un pilastro fondamentale del modello Zero Trust consigliato da Microsoft.

Assicurarsi che siano seguite le procedure consigliate per la sicurezza per tutti i sistemi di sviluppo e l'infrastruttura che li ospita (macchine virtuali, contenitori, dispositivi di rete e altro ancora).

Minimo temporaneo: assicurarsi che tutti usino l'autenticazione a più fattori e possano accedere solo ai sistemi necessari per eseguire le attività quotidiane.

Standard : assicurarsi che i componenti dell'infrastruttura che ospitano il carico di lavoro (ad esempio macchine virtuali, contenitori, rete e sistemi di gestione delle identità) soddisfino le procedure consigliate per la sicurezza per la gestione delle identità e degli accessi, inclusa la protezione dell'accesso con privilegi.

Sicurezza elevata: implementare una strategia Zero Trust completa che incorpora MFA, Identity Threat Detection and Response e Cloud Infrastructure Entitlement Management (CIEM). Eseguire un modello di minaccia specifico del carico di lavoro dei sistemi di identità e dei componenti che supportano ogni carico di lavoro con sicurezza elevata.

Le identità gestite sono il metodo di autenticazione più sicuro e preferito laddove possibile. L'uso di token e segreti è meno sicuro a causa della necessità di archiviarli e recuperarli a livello di applicazione. Inoltre, le identità gestite vengono eseguite automaticamente senza la necessità di intervento manuale.

Altri dettagli e risorse includono:

Controlli host/contenitore/ambiente

Questo controllo supporta la pratica SDL continua 8 - Garantire la sicurezza della piattaforma operativa e la pratica 6 - Proteggere l'ambiente di progettazione.

Assicurarsi che vengano seguite le procedure consigliate per la sicurezza per tutte le risorse di calcolo e gli ambienti di hosting per tutti gli elementi tecnici del ciclo di vita dello sviluppo. Gli attori delle minacce hanno metodi sofisticati e automazione per gli attacchi all'infrastruttura e agli endpoint utente usati di frequente sia nei sistemi di produzione che nei processi di sviluppo. La sicurezza dell'infrastruttura è un pilastro fondamentale del modello Zero Trust consigliato da Microsoft.

Questo controllo deve includere tutti gli elementi del ciclo di vita operativo e di sviluppo, tra cui, a titolo esemplificativo:

  • Workstation e ambienti IT/operativi generali
  • Workstation e ambienti di sviluppo dedicati
  • Infrastruttura della pipeline CI/CD
  • Ambienti di hosting del carico di lavoro
  • Qualsiasi altro sistema di sviluppo.

Questo controllo include qualsiasi risorsa in grado di eseguire qualsiasi codice incluso, ma non limitato a:

  • Host e macchine virtuali (VM) di macchine virtuali
  • Contenitori e infrastruttura di contenitori
  • Piattaforme di hosting di applicazioni, script e codice
  • Sottoscrizioni cloud/account e registrazioni
  • Workstation per sviluppatori, utenti e it Amministrazione

Assicurarsi di applicare le procedure consigliate per la sicurezza ai componenti dell'infrastruttura, inclusi gli aggiornamenti della sicurezza (patch), le configurazioni di sicurezza di base e altro ancora.

Minimo temporaneo: applicare configurazioni aziendali standard per host e sottoscrizioni.

Standard : assicurarsi che l'infrastruttura soddisfi le procedure consigliate per la sicurezza descritte in Microsoft Cloud Security Benchmark (MCSB).

Sicurezza elevata: applicare rigorosamente gli standard MCSB ed eseguire un modello di minaccia specifico del carico di lavoro dell'infrastruttura che supporta ogni carico di lavoro con sicurezza elevata.

Altri dettagli e risorse includono:

Controlli di accesso alla rete

Questo controllo supporta la pratica SDL continua 8 - Garantire la sicurezza della piattaforma operativa e la pratica 6 - Proteggere l'ambiente di progettazione.

Assicurarsi che le procedure consigliate per la sicurezza per la gestione degli accessi in rete siano seguite per tutti gli elementi tecnici dell'ambiente di sviluppo, la pipeline CI/CD, l'ambiente del carico di lavoro operativo e altri sistemi di sviluppo. Gli attori delle minacce hanno metodi sofisticati e automazione per gli attacchi di identità che usano frequentemente sia nei sistemi di produzione che nei processi di sviluppo. La sicurezza di rete è un pilastro fondamentale del modello Zero Trust consigliato da Microsoft.

La sicurezza di rete deve includere:

  • Protezione rete esterna: isolamento dal traffico esterno/Internet non richiesto e dalla mitigazione dei tipi di attacco noti. Questo isolamento in genere assume la forma di firewall Internet, web application firewall (WAF) e soluzioni di sicurezza API.
  • Protezione della rete interna: isolamento dal traffico interno non richiesto (da altri percorsi di rete aziendali). Questo isolamento può usare controlli simili come protezione di rete esterna e potrebbe essere granulare per il carico di lavoro o per singoli componenti e indirizzi IP specifici.
  • Mitigazioni Denial of Service: protezione da attacchi DDoS (Distributed Denial of Service) e altri attacchi Denial of Service.
  • Security Service Edge (S edizione Standard): uso di microsegmentazione lato client per fornire l'accesso sicuro direttamente alle risorse, inclusa l'applicazione di criteri Zero Trust.

Assicurarsi che siano seguite le procedure consigliate per la sicurezza per tutti i sistemi di sviluppo e l'infrastruttura che li ospita (macchine virtuali, contenitori, dispositivi di rete e altro ancora).

Minimo temporaneo: applicare configurazioni aziendali standard per il carico di lavoro.

Standard : assicurarsi che tutti i sistemi dispongano di protezione di rete esterna, protezione DDoS e almeno protezione di rete interna per ogni carico di lavoro.

Sicurezza elevata: tutte le protezioni standard e la granularità elevata delle protezioni di rete interne, il tunneling forzato del traffico del server in uscita tramite meccanismi di protezione della rete esterna e un modello di minaccia specifico del carico di lavoro dell'infrastruttura di rete che supporta ogni carico di lavoro con sicurezza elevata.

Altri dettagli e risorse includono:

Monitoraggio, risposta e ripristino

Questo controllo supporta la pratica CONTINUA SDL 9 - Implementare il monitoraggio e la risposta per la sicurezza.

Assicurarsi che i team delle operazioni di sicurezza (SecOps/SOC) abbiano visibilità, rilevamento delle minacce e procedure di risposta per carichi di lavoro (API e app) e l'infrastruttura che li ospita. Assicurarsi che i processi e gli strumenti tra team tra team tra secops e infrastruttura/carico di lavoro consentano un ripristino rapido dopo un attacco.

Questo controllo mantiene la sicurezza del carico di lavoro una volta che è in produzione e attivamente in esecuzione nell'organizzazione. Questo processo deve essere integrato con la funzionalità delle operazioni di sicurezza esistenti che rileva e risponde agli eventi imprevisti di sicurezza.

Il monitoraggio della sicurezza per i carichi di lavoro personalizzati combina soluzioni XDR (Extended Detection and Response) per i componenti comuni analizzando i log e altri dati dell'applicazione per rilevare e analizzare potenziali minacce alla sicurezza. I dati dell'applicazione personalizzati includono spesso informazioni sulle richieste degli utenti, sull'attività dell'applicazione, sui codici di errore, sul traffico di rete, su altri dettagli rilevanti dell'applicazione, dei database, degli endpoint di rete e di altri componenti di sistema.

Questi dati vengono quindi migliorati con informazioni dettagliate dall'intelligence sulle minacce in tempo reale per identificare i modelli di comportamento anomalo che potrebbero indicare potenziali tentativi di infiltrazione della rete. Dopo aver aggregato, correlato e normalizzato, la piattaforma SIEM (Security Information and Event Management) XDR e Security Information and Event Management (SIEM) offre azioni correttive.

Minimo temporaneo: distribuire le funzionalità XDR nell'ambiente per monitorare il traffico dei dispositivi degli utenti finali.

Standard : distribuire rilevamenti SIEM personalizzati e XDR che identificano il comportamento anomalo rispetto all'ambiente complessivo. Questo profilo può includere rilevamenti personalizzati per singoli carichi di lavoro.

Sicurezza elevata: controlli standard e rilevamenti personalizzati per carico di lavoro basati su informazioni dettagliate dalla modellazione delle minacce del carico di lavoro. Combinare questo profilo con l'intelligenza artificiale per fornire consapevolezza contestuale alle raccomandazioni di correzione.

Passaggi successivi

Adottare questi controlli di sicurezza e adattarli ai requisiti di tolleranza e produttività dei rischi dell'organizzazione. È consigliabile usare un approccio di miglioramento continuo in cui si compila continuamente verso lo stato ideale.

Iniziare assegnando priorità ai controlli e ai livelli di destinazione ideali minimi. Assicurarsi prima di tutto di avere un impatto positivo sulla sicurezza e modifiche a basso attrito. Classificare in ordine di priorità, implementare e integrare il primo controllo, quindi ripetere il processo con il controllo successivo.

È necessario classificare in ordine di priorità le basi critiche prima a causa dell'ampio impatto positivo e dell'analisi delle credenziali e dei segreti a causa dell'impatto elevato e dell'uso frequente degli utenti malintenzionati.