Condividi tramite

Sicurezza di DevOps

La sicurezza devOps integra le procedure di sicurezza per tutto il ciclo di vita dello sviluppo software (SDLC) dalla progettazione iniziale e dalla codifica tramite compilazione, test e distribuzione all'ambiente di produzione. A differenza degli approcci di sicurezza tradizionali che considerano la sicurezza come un controllo finale, la sicurezza DevOps incorpora controlli di sicurezza, test automatizzati e monitoraggio continuo in ogni fase della pipeline di sviluppo. Questo approccio riconosce che la distribuzione di software moderna si basa su pipeline CI/CD complesse, dipendenze di terze parti, infrastruttura come codice e distribuzioni automatizzate, che introducono potenziali vettori di attacco che sfruttano attivamente gli avversari. Applicando principi Zero Trust (presupporre violazioni, verificare in modo esplicito) e strategie di difesa approfondite, la sicurezza DevOps garantisce che il codice, le dipendenze, le configurazioni dell'infrastruttura e i processi della pipeline rimangano affidabili e resistenti alle manomissioni dalla progettazione attraverso la produzione. Senza una sicurezza DevOps completa, le organizzazioni devono affrontare rischi critici, tra cui attacchi alla supply chain, esposizione delle credenziali nelle pipeline, inserimento di codice dannoso, immagini contenitore vulnerabili e modifiche all'infrastruttura non autorizzate che possono stabilire backdoor persistenti che interessano tutti i consumer downstream.

Ecco i tre pilastri principali del dominio di sicurezza di DevOps Security.

Proteggere la progettazione e la supply chain: Eseguire la modellazione strutturata delle minacce in anticipo. Proteggere la supply chain con l'analisi delle dipendenze e delle licenze, la gestione delle vulnerabilità e la generazione SBOM. Verificare la provenienza e l'integrità di tutti i componenti.

Controlli correlati:

Spostare a sinistra i controlli di sicurezza: Spostare a sinistra i controlli di sicurezza integrando SAST, scansione dei segreti, scansione IaC e DAST nella pipeline CI/CD. Centralizzare la gestione dei segreti (ad esempio, Key Vault), limitare l'autorità di modifica della pipeline e analizzare e proteggere continuamente gli artefatti (ad esempio immagini di contenitori e macchine virtuali) prima della distribuzione.

Controlli correlati:

Monitorare e controllare le attività DevOps: Raccogliere e inoltrare i log di controllo e sicurezza di DevOps a una piattaforma di analisi centrale per la correlazione e la risposta. Rilevare le modifiche non autorizzate della pipeline, le escalation di privilegi, i commit anomali e l'esecuzione fuori orario.

Controlli correlati:

DS-1: Eseguire la modellazione delle minacce

Principio di sicurezza

Implementare la modellazione sistematica delle minacce usando la metodologia STRIDE durante la fase di progettazione per identificare potenziali minacce alla sicurezza, classificare in ordine di priorità i rischi e implementare mitigazioni appropriate prima dell'inizio dello sviluppo del codice. Questo approccio di spostamento a sinistra riduce i costi di correzione e migliora il comportamento di sicurezza complessivo.

Rischio da mitigare

Le organizzazioni che non eseguono la modellazione delle minacce durante la fase di progettazione operano con punti ciechi critici che sfruttano sistematicamente gli avversari. Senza analisi sistematica delle minacce:

  • Difetti architetturali tardivi: Le vulnerabilità di progettazione incorporata richiedono un refactoring costoso nell'ambiente di produzione, con costi di correzione notevolmente superiori rispetto alla risoluzione dei problemi durante la fase di progettazione.
  • Superfici di attacco non identificate: I vettori di minaccia, ad esempio limiti di attendibilità non sicuri, requisiti di autenticazione mancanti o protezioni inadeguate del flusso di dati rimangono non documentati, consentendo agli utenti malintenzionati di sfruttare i punti deboli noti che i difensori non riconoscono.
  • Controlli di sicurezza insufficienti: I controlli di sicurezza mancanti o inadeguati (crittografia, autenticazione, autorizzazione, registrazione di controllo) derivano dall'analisi incompleta delle minacce, creando lacune sfruttabili nella strategia di difesa approfondita.
  • Punti ciechi di conformità: I requisiti normativi (PCI-DSS, HIPAA, SOX) che imponeno la convalida della progettazione sicura non possono essere soddisfatti senza modelli di minaccia documentati e prove di mitigazione.
  • Accumulo del debito di sicurezza: Le aggiunte di funzionalità continue senza la modellazione delle minacce creano un debito tecnico di sicurezza composto, rendendo i sistemi progressivamente più vulnerabili e difficili da proteggere retroattivamente.

La mancanza di modellazione delle minacce aumenta la probabilità di violazione, estende il tempo di attesa e determina costi di correzione molto più elevati rispetto alla mitigazione anticipata della fase di progettazione.

MITRE ATT&CK

  • Accesso iniziale (TA0001): exploit dell'applicazione pubblica (T1190) sfruttando i difetti dell'architettura nell'autenticazione, nella gestione delle sessioni o nella convalida di input che la modellazione delle minacce identificherebbe.
  • Escalation dei privilegi (TA0004): abuso del meccanismo di controllo dell'elevazione (T1548) sfruttando una separazione dei privilegi insufficiente o controlli di autorizzazione mancanti nell'architettura di sistema.
  • Evasione della difesa (TA0005): compromissione delle difese (T1562) sfruttando la mancanza di registrazione degli audit, i gap di monitoraggio o la telemetria di sicurezza insufficiente progettata nel sistema.

DS-1.1: Implementare la modellazione delle minacce basata su STRIDE

La modellazione sistematica delle minacce durante la fase di progettazione fornisce le basi per l'architettura software sicura identificando le vulnerabilità prima dell'inizio dello sviluppo. Risolvere i problemi di sicurezza nella fase di progettazione riduce drasticamente i costi di correzione e impedisce che i difetti dell'architettura diventino incorporati nei sistemi di produzione. L'identificazione anticipata delle minacce garantisce che i controlli di sicurezza siano integrati nell'architettura anziché essere adattati in un secondo momento.

Implementare l'approccio strutturato seguente per stabilire la modellazione delle minacce:

  • Stabilire una metodologia STRIDE sistematica: Stabilire una modellazione sistematica delle minacce come attività di progettazione obbligatoria usando la metodologia STRIDE (spoofing, manomissione, ripudio, divulgazione di informazioni, Denial of Service, elevazione dei privilegi). Per iniziare, creare diagrammi di flusso di dati (DFD) che eseguono il mapping di componenti di sistema, flussi di dati, limiti di attendibilità e dipendenze esterne. Per ogni componente e flusso di dati, valutare sistematicamente le potenziali minacce in tutte e sei le categorie STRIDE, classificare in ordine di priorità i rischi in base alla probabilità e all'impatto e documentare mitigazioni specifiche prima dell'inizio dello sviluppo.

  • Usare gli strumenti di modellazione delle minacce strutturati: Usare strumenti di modellazione delle minacce strutturati come Microsoft Threat Modeling Tool per mantenere la coerenza e sfruttare modelli predefiniti per modelli di architettura comuni (applicazioni Web, API, microservizi, soluzioni IoT). Lo strumento facilita la creazione di DFD, l'identificazione automatizzata delle minacce in base ai tipi di componenti e ai flussi di dati e genera raccomandazioni di mitigazione praticabili con i controlli di sicurezza associati. Archiviare i modelli di minaccia come artefatti versionati nel repository, insieme alla documentazione dell'architettura.

  • Integrazione nei flussi di lavoro di sviluppo: Integrare gli output di modellazione delle minacce direttamente nei flussi di lavoro di sviluppo esportando minacce identificate in elementi di lavoro di Azure DevOps con criteri di proprietà, priorità e accettazione chiari. Implementare controlli di revisione dell'architettura che richiedono modelli di minaccia completati prima dell'approvazione della progettazione e stabilire controlli delle richieste pull che attivano revisioni del modello di minaccia quando vengono rilevate modifiche dell'architettura. Ciò garantisce che l'analisi delle minacce rimanga sincronizzata con l'evoluzione del sistema durante tutto il ciclo di vita dello sviluppo.

DS-1.2: Automatizzare l'integrazione dell'analisi delle minacce

La scalabilità della modellazione delle minacce tra organizzazioni di grandi dimensioni richiede l'automazione e la funzionalità distribuita per impedire che le verifiche di sicurezza diventino colli di bottiglia per lo sviluppo. I flussi di lavoro automatizzati di identificazione delle minacce incorporati nei processi di avvio del progetto e richiesta pull garantiscono un'analisi coerente della sicurezza senza intervento manuale per ogni progetto. La creazione di competenze di sicurezza all'interno dei team di sviluppo tramite programmi di abilitazione crea procedure di modellazione delle minacce sostenibili e scalabili.

Implementare queste funzionalità di automazione e abilitazione:

  • Scalabilità tramite automazione e abilitazione: Ridimensionare la modellazione delle minacce nell'organizzazione tramite automazione e abilitazione. Incorporare questionari di sicurezza nei modelli di avvio del progetto che valutano automaticamente il livello di rischio, determinano i requisiti di modellazione delle minacce e assegnano checkpoint di revisione della sicurezza appropriati in base alla classificazione dei dati, all'esposizione esterna e all'ambito normativo. Automatizzare i trigger di revisione dell'architettura nei flussi di lavoro delle richieste pull che rilevano modifiche ai limiti di sistema, ai flussi di autenticazione o alla logica di gestione dei dati, deviando tali modifiche agli architetti della sicurezza per la validazione del modello di minaccia.

  • Creare funzionalità distribuite con i promotori della sicurezza: Stabilire un programma Security Champions per creare funzionalità di modellazione delle minacce distribuite all'interno dei team di sviluppo. Formare i promotori sulla metodologia STRIDE, fornire loro strumenti e modelli di modellazione delle minacce e consentire loro di facilitare le sessioni di modellazione delle minacce per i team. I campioni della sicurezza fungono da prima linea di revisione, escalando scenari complessi ai team di sicurezza centralizzati, consentendo alla maggior parte della modellazione delle minacce di avvenire senza creare colli di bottiglia.

Implementazione automatizzata dell'analisi delle minacce:

  • Valutazione basata su questionario: Questionari sulla sicurezza standardizzati integrati nei modelli di Azure DevOps per l'identificazione coerente delle minacce
  • Programma dei promotori della sicurezza: Promotori della sicurezza designati in ogni team di sviluppo addestrati alla facilitazione della modellazione delle minacce
  • Automazione della revisione dell'architettura: Controlli automatici nelle richieste pull per gli aggiornamenti del diagramma dell'architettura che richiedono revisioni del modello di minaccia
  • Modello di minaccia come codice: Definizioni dei modelli di minaccia controllati dalla versione usando formati strutturati (JSON/YAML) che consentono l'analisi automatizzata

Esempio di implementazione

Un'organizzazione di servizi finanziari ha subito una violazione dei dati quando gli utenti malintenzionati hanno sfruttato un difetto di autorizzazione nell'API di pagamento che non è mai stata identificata durante lo sviluppo, causando transazioni fraudolente significative e multe normative.

Sfida: Architettura di microservizi con numerose API distribuite senza revisione della sicurezza. I team di sviluppo non hanno competenze di sicurezza per identificare le minacce. Problemi di sicurezza dell'architettura individuati solo dopo gli eventi imprevisti di produzione.

Approccio alla soluzione:

  • Modellazione delle minacce STRIDE: Implementato Microsoft Threat Modeling Tool per tutti i microservizi e gli endpoint API con diagrammi flusso di dati che illustrano l'architettura e i flussi di dati sensibili.
  • Programma dei promotori della sicurezza: Moderatori di modellazione delle minacce addestrati in ogni team di sviluppo che abilitano la sicurezza in base alla progettazione senza creare colli di bottiglia nella squadra di sicurezza centrale.
  • Integrazione automatica del flusso di lavoro: Revisioni integrate del modello di minaccia nei flussi di lavoro delle richieste pull di Azure DevOps che richiedono l'approvazione della sicurezza per le modifiche dell'architettura.

Risultato: Sono stati identificati numerosi problemi di sicurezza pre-distribuzione che impediscono potenziali violazioni. Riduzione sostanziale delle vulnerabilità di sicurezza nell'ambiente di produzione. Le verifiche di sicurezza hanno aggiunto un tempo minimo al ciclo di sviluppo.

Livello di criticità

Indispensabile.

Mapping controlli

  • NIST SP 800-53 Rev.5: SA-11, SA-15, PL-8, RA-3, RA-5
  • PCI-DSS v4: 6.3.1, 6.3.2, 12.3.1
  • Controlli CIS v8.1: 14.2, 14.3
  • NIST CSF v2.0: ID.RA-3, PR.IP-2
  • ISO 27001:2022: A.5.12, A.8.25
  • SOC 2: CC3.2, CC7.1

DS-2: Proteggere la catena di approvvigionamento software

Principio di sicurezza

Implementare zero trust per le dipendenze verificando la provenienza, l'integrità e il comportamento di sicurezza di tutti i componenti di terze parti prima dell'integrazione. Analizza continuamente le dipendenze per individuare le vulnerabilità, mantiene un Software Bill of Materials (SBOM) completo e applica aggiornamenti di sicurezza automatici per ridurre al minimo la superficie di attacco della supply chain.

Rischio da mitigare

Gli attacchi della supply chain software rappresentano minacce critiche perché gli avversari sfruttano le relazioni di trust tra organizzazioni e componenti di terze parti per ottenere un impatto diffuso con un impegno minimo. Senza sicurezza completa della supply chain:

  • Dipendenze dannose: Gli avversari inseriscono backdoor nelle librerie open source più diffuse (attacchi in stile SolarWinds) o creano pacchetti di tipo typosquatted che eseguono codice dannoso durante l'installazione o il runtime.
  • Librerie di terze parti vulnerabili: Le CVE note nelle dipendenze (Vulnerabilità log4Shell, Heartbleed, Struts) rimangono senza patch per settimane o mesi a causa della mancanza di visibilità e gestione automatica delle vulnerabilità.
  • Artefatti di compilazione compromessi: Gli utenti malintenzionati manomette i file binari compilati, le immagini del contenitore o i pacchetti di distribuzione durante l'archiviazione o il transito, inserendo malware che ignora la revisione del codice sorgente.
  • Attacchi di confusione sulle dipendenze: Gli attori malintenzionati caricano pacchetti in repository pubblici con nomi corrispondenti a pacchetti privati interni, sfruttando la logica di risoluzione di Gestione pacchetti per sostituire il codice dannoso.
  • Rischi di dipendenza transitiva: Le vulnerabilità nelle dipendenze indirette (dipendenze delle dipendenze) rimangono invisibili senza l'analisi approfondita dell'albero delle dipendenze e la generazione SBOM.
  • Mancanza di verifica della provenienza: L'assenza di verifica crittografica abilita gli attacchi di sostituzione dei pacchetti in cui i pacchetti legittimi vengono sostituiti con versioni dannose.

La compromissione della filiera di approvvigionamento consente un impatto significativo, backdoor persistenti nelle librerie fidate e un'elevata capacità di evasione a causa del loro aspetto legittimo.

MITRE ATT&CK

  • Accesso iniziale (TA0001): compromissione della supply chain (T1195.001) tramite compromissione delle dipendenze software e degli strumenti di sviluppo per ottenere un punto di appoggio iniziale negli ambienti di destinazione e una relazione attendibile (T1199) sfruttando la fiducia tra organizzazioni e fornitori di software di terze parti per fornire aggiornamenti dannosi.
  • Esecuzione (TA0002): interprete dei comandi e degli script (T1059) che esegue codice dannoso incorporato negli script di installazione delle dipendenze o negli hook post-installazione.
  • Persistenza (TA0003): compromissione del file binario del software client (T1554) che incorpora backdoor nelle librerie compilate che vengono mantenute tra gli aggiornamenti dell'applicazione.

DS-2.1: Implementare l'analisi e la gestione delle dipendenze

La gestione completa della sicurezza delle dipendenze impedisce attacchi alla supply chain mantenendo visibilità su tutti i componenti di terze parti, monitorando continuamente le vulnerabilità e automatizzando i processi di correzione. Le applicazioni moderne si basano su centinaia o migliaia di dipendenze (dirette e transitive), rendendo impossibile la valutazione manuale della sicurezza e creando una superficie di attacco estesa tramite librerie vulnerabili. L'analisi automatizzata delle dipendenze con il monitoraggio continuo garantisce alle organizzazioni di rilevare e correggere le vulnerabilità prima dello sfruttamento.

Stabilire la sicurezza delle dipendenze continue tramite queste funzionalità principali:

  • Stabilire visibilità completa e generazione SBOM: Stabilire una gestione continua della sicurezza delle dipendenze con tre funzionalità principali: visibilità completa, rilevamento automatizzato delle vulnerabilità e correzione proattiva. Iniziare generando inventari delle dipendenze completi che eseguono il mapping di dipendenze dirette (dichiarate in modo esplicito nei manifesti del pacchetto) e dipendenze transitive (dipendenze delle dipendenze) in tutti i repository. Mantenere l'elenco materiali software (SBOM) in formati standard del settore (SPDX, CycloneDX) per la conformità normativa e la prontezza alla risposta agli incidenti.

  • Implementare l'analisi e la correzione automatizzate delle vulnerabilità: Implementare l'analisi automatizzata delle vulnerabilità che monitora continuamente le dipendenze dal database di vulnerabilità nazionale (NVD), dal database consultivo GitHub e dagli avvisi di sicurezza specifici del linguaggio. Configurare avvisi in tempo reale quando vengono divulgate nuove vulnerabilità che influiscono sullo stack di dipendenze, con instradamento basato sulla gravità verso le squadre appropriate. Abilitare le funzionalità di aggiornamento della sicurezza automatizzato che generano pull request con aggiornamenti delle versioni delle dipendenze, inclusi i test di compatibilità e la risoluzione intelligente dei conflitti di fusione per ridurre il carico di correzione manuale.

  • Integrare la convalida della sicurezza nei flussi di lavoro di sviluppo: Integrare la convalida della sicurezza delle dipendenze direttamente nei flussi di lavoro di sviluppo tramite revisioni delle pull request che valutano automaticamente l'impatto sulla sicurezza delle modifiche alle dipendenze, contrassegnando le nuove dipendenze con vulnerabilità note, questioni di conformità delle licenze o caratteristiche sospette (typosquatting, mancanza di reputazione del gestore). Stabilire controlli di approvazione per le modifiche alle dipendenze ad alto rischio e applicare criteri che impediscono alle dipendenze con vulnerabilità critiche di unire i rami protetti.

  • Estendere la visibilità agli ambienti di produzione: Estendere la visibilità oltre il codice sorgente agli ambienti distribuiti usando strumenti come Microsoft Defender for Cloud DevOps Security per correlare le dipendenze del codice con carichi di lavoro in esecuzione, identificare i percorsi di attacco tramite catene di dipendenze e classificare in ordine di priorità la correzione in base all'esposizione effettiva della produzione anziché al solo rischio teorico. Strumenti come GitHub Advanced Security offrono una visualizzazione completa del grafico delle dipendenze, aggiornamenti automatizzati basati su Dependabot e supporto di modelli di vulnerabilità personalizzati per ecosistemi di pacchetti proprietari.

Esempio di implementazione

Un'organizzazione sanitaria ha scoperto un pacchetto npm dannoso nell'applicazione di produzione che esfiltrava i dati dei pazienti per mesi. L'indagine ha rivelato dipendenze vulnerabili estese con CVE note, inclusa la vulnerabilità critica Log4Shell.

Sfida: Migliaia di dipendenze in centinaia di repository senza visibilità sulle vulnerabilità o sui pacchetti dannosi. Revisioni manuali delle dipendenze richiedevano settimane per ogni applicazione. Il controllo normativo ha identificato lacune critiche per la catena di approvvigionamento.

Approccio alla soluzione:

  • Gestione automatica delle vulnerabilità: Abilitato GitHub Advanced Security con Dependabot che analizza le dipendenze e crea automaticamente richieste pull per gli aggiornamenti di sicurezza.
  • Trasparenza della catena di approvvigionamento: Implementato lo strumento Microsoft SBOM che genera la fatturazione software dei materiali in formato SPDX per la conformità alle normative e la risposta agli eventi imprevisti.
  • Verifica del pacchetto: Configurato Azure Artifacts con verifica della firma e blocco delle dipendenze che impediscono attacchi di confusione e sostituzione di pacchetti non autorizzati.
  • Monitoraggio della sicurezza devOps: Distribuzione di Microsoft Defender for Cloud DevOps Security per la tracciabilità da codice a cloud.

Risultato: Rilevate e risolte rapidamente dipendenze vulnerabili estese. Impedito più eventi imprevisti di pacchetti dannosi tramite la verifica automatizzata. È stata ottenuta la conformità alle normative con la documentazione completa di SBOM.

Livello di criticità

Indispensabile.

Mapping controlli

  • NIST SP 800-53 Rev.5: SR-3, SR-4, SR-6, SA-12, SA-15(9), RA-5
  • PCI-DSS v4: 6.2.4, 6.3.2, 6.3.3
  • Controlli CIS v8.1: 16.1, 16.2, 16.11
  • NIST CSF v2.0: ID.SC-2, ID.SC-4, DE.CM-8
  • ISO 27001:2022: A.5.19, A.5.22, A.5.23
  • SOC 2: CC3.2, CC8.1

DS-3: Proteggere l'infrastruttura DevOps

Principio di sicurezza

Implementare la difesa avanzata per creare un'infrastruttura tramite la gestione completa dei segreti, i controlli di accesso alle pipeline con controlli di approvazione, la configurazione sicura dell'agente di compilazione e il monitoraggio continuo. Eliminare le credenziali hardcoded e applicare l'accesso con privilegi minimi per proteggere l'integrità del processo di sviluppo e distribuzione del software.

Rischio da mitigare

L'infrastruttura DevOps non sicura crea vulnerabilità critiche che sfruttano gli avversari per compromettere l'intera catena di distribuzione del software. Senza sicurezza completa dell'infrastruttura:

  • Pipeline CI/CD compromesse: Gli attaccanti ottengono l'accesso alle pipeline di costruzione tramite credenziali rubate, vulnerabilità sfruttate o accesso insider, abilitando l'iniezione di codice, la manomissione degli artefatti o la manipolazione della distribuzione che influisce su tutti gli utenti downstream.
  • Segreti esposti nei log di compilazione e negli artefatti: Le credenziali hardcoded, le chiavi API, i certificati e le stringhe di connessione vengono perse tramite log della pipeline, messaggi di errore o artefatti compilati, fornendo agli utenti malintenzionati l'accesso diretto agli ambienti di produzione.
  • Modifiche della pipeline non autorizzate: La mancanza di flussi di lavoro di controllo delle modifiche e approvazione consente agli attori malintenzionati di modificare le definizioni della pipeline, inserire passaggi di compilazione dannosi o modificare le configurazioni di distribuzione senza rilevamento.
  • Controlli di accesso insufficienti: Le assegnazioni di ruolo eccessivamente permissive e la mancanza di separazione dei compiti consentono lo spostamento laterale, l'escalation dei privilegi e la definizione dell'accesso permanente all'interno dell'infrastruttura DevOps.
  • Agenti di compilazione non sicuri: Gli agenti di compilazione senza patch, configurati in modo errato o compromessi forniscono agli utenti malintenzionati l'accesso permanente all'ambiente di compilazione e ai potenziali punti pivot nelle reti di produzione.
  • Audit trail mancanti: La registrazione e il monitoraggio inadeguati delle attività DevOps impediscono il rilevamento di accessi non autorizzati, modifiche sospette o minacce interne.

La compromissione dell'infrastruttura consente agli utenti malintenzionati di inserire codice all'origine, ignorare le pipeline attendibili e influire su ogni applicazione downstream.

MITRE ATT&CK

  • Accesso iniziale (TA0001): account validi (T1078) che usano credenziali rubate o segreti dell'entità servizio per accedere alle piattaforme e alle pipeline DevOps.
  • Persistenza (TA0003): manipolazione degli account (T1098) creazione di principali di servizio backdoor, token di accesso personali o chiavi SSH per mantenere l'accesso.
  • Accesso alle credenziali (TA0006): credenziali non protette (T1552.001) che raccolgono segreti dai log della pipeline, dalle variabili di ambiente o dai file di configurazione.
  • Evasione della difesa (TA0005): ostacolamento delle difese (T1562) disabilitando i passaggi di analisi della sicurezza, la registrazione dei log di controllo o i controlli di approvazione delle definizioni della pipeline.

DS-3.1: Implementare la gestione dei segreti per le pipeline

La gestione centralizzata dei segreti elimina l'esposizione delle credenziali nelle pipeline DevOps rimuovendo i segreti hardcoded dal codice, dai file di configurazione e dalle definizioni di pipeline. Le credenziali incorporate nelle pipeline YAML, nelle variabili di ambiente o nei repository di origine rappresentano il vettore di attacco primario per la compromissione della pipeline, consentendo agli utenti malintenzionati che ottengono l'accesso ai repository o ai log per estrarre le credenziali di produzione. L'implementazione dell'archiviazione segreta protetta da crittografia con il recupero dinamico e i modelli di accesso JUST-In-Time impediscono il furto di credenziali mantenendo al contempo l'efficienza operativa.

Configurare la gestione dei segreti con questi controlli di sicurezza:

  • Eliminare le credenziali hardcoded con l'archiviazione centralizzata: Eliminare le credenziali hardcoded dalle definizioni della pipeline e dal codice sorgente centralizzando tutti i segreti nell'infrastruttura di gestione dei segreti dedicata con controlli di accesso crittografici e audit trail completi. Stabilire il principio che i segreti non devono mai essere archiviati nei file YAML della pipeline, nelle variabili di ambiente visibili nei log o nei file di configurazione nei repository. Questi sono i vettori principali per l'esposizione delle credenziali negli ambienti DevOps.

  • Configurare il recupero di segreti dinamici con identità gestite: Implementare l'archiviazione segreta centralizzata usando soluzioni come Azure Key Vault che forniscono archiviazione segreta crittografata, criteri di accesso granulari, rotazione automatica dei segreti e registrazione completa dei controlli. Configurare le pipeline per recuperare i segreti in modo dinamico in fase di esecuzione tramite connessioni del servizio sicure anziché incorporarle nelle definizioni della pipeline. Usare le identità gestite o la federazione delle identità dei carichi di lavoro per autenticare l'accesso delle pipeline agli archivi segreti, eliminando la necessità di credenziali dei principal del servizio di lunga durata che diventano obiettivi per il furto.

  • Applicare l'accesso JUST-In-Time con i controlli di approvazione: Applicare modelli di accesso just-in-time ai segreti in cui i segreti vengono recuperati solo quando necessario, con revoca automatica dopo il completamento della pipeline per ridurre al minimo l'esposizione della durata delle credenziali. Implementare restrizioni di accesso con vincoli di tempo e richiedere l'autorizzazione a più persone (controlli di approvazione) per l'accesso alla pipeline ai segreti di produzione, assicurando che nessun singolo account compromesso possa accedere alle credenziali sensibili senza verifica aggiuntiva.

  • Stabilire controlli di accesso all'infrastruttura a più livelli: Stabilire controlli di accesso a più livelli per l'infrastruttura DevOps: limitare i diritti di modifica della pipeline al personale sottoposto a revisione della sicurezza, applicare autorizzazioni specifiche dell'ambiente che richiedono l'approvazione per le distribuzioni di produzione, implementare restrizioni di connessione al servizio a livello di repository impedendo alle pipeline di accedere ai segreti all'esterno dell'ambito previsto e distribuire agenti di compilazione self-hosted con isolamento di rete per carichi di lavoro sensibili. Integrare l'analisi della sicurezza distribuita come codice nell'infrastruttura nelle pipeline per impedire la distribuzione di risorse configurate in modo errato che potrebbero esporre segreti o creare percorsi di accesso non autorizzati.

Esempio di implementazione

Un'azienda retail ha subito una violazione quando gli utenti malintenzionati hanno usato credenziali rubate del principale del servizio rilevate nei log della pipeline per accedere ai database di produzione, esponendo milioni di record dei clienti.

Sfida: Stringhe di connessione del database e chiavi API codificate nelle variabili della pipeline. Le autorizzazioni della pipeline eccessivamente permissive hanno consentito a qualsiasi sviluppatore di eseguire la distribuzione nell'ambiente di produzione. La compromissione dell'agente di compilazione ha fornito l'accesso permanente all'infrastruttura.

Approccio alla soluzione:

  • Gestione centralizzata dei segreti: L'implementazione dell'integrazione di Azure Key Vault ha eliminato i segreti codificati in modo fisso dalle pipeline. È stata configurata un'autenticazione dell'identità gestita eliminando il rischio di esposizione delle credenziali.
  • Controlli di accesso alla pipeline: Stabilite le barriere di approvazione e autorizzazioni specifiche per ogni ambiente utilizzando Azure DevOps Environments che richiedono l'approvazione del team di sicurezza per i deployment in produzione.
  • Agenti di compilazione con protezione avanzata: Agenti self-hosted distribuiti con protezione avanzata e isolamento di rete per carichi di lavoro sensibili che elaborano dati regolamentati.
  • Analisi della sicurezza dell'infrastruttura: Convalida integrata della sicurezza per i modelli ARM e le configurazioni Terraform che impedisce l'implementazione di configurazioni errate.

Risultato: Eliminazione dei segreti dai log della pipeline che impediscono il furto di credenziali. Eliminazione delle distribuzioni di produzione non autorizzate. Errori di configurazione dell'infrastruttura rilevati e bloccati prima della distribuzione.

Livello di criticità

Indispensabile.

Mapping controlli

  • NIST SP 800-53 Rev.5: AC-2, AC-3, AC-6, SC-12, SC-13, AU-2, AU-6
  • PCI-DSS v4: 8.3.2, 8.6.1, 8.6.3, 12.3.3
  • Controlli CIS v8.1: 4.1, 4.7, 6.1, 6.5
  • NIST CSF v2.0: PR.AC-4, Pull request DS-5, DE.CM-7
  • ISO 27001:2022: A.5.15, A.5.16, A.8.3
  • SOC 2: CC6.1, CC6.6, CC6.7

DS-4: Integrare il test statico di sicurezza delle applicazioni (SAST)

Principio di sicurezza

Implementare test di sicurezza automatizzati completi tramite più scanner SAST (Static Application Security Testing) specializzati integrati in ogni processo di compilazione. Usare la copertura multiscan per il rilevamento esaustivo, implementare la scansione dei segreti con protezione dei push e distribuire l'analisi del codice semantico per identificare e bloccare le vulnerabilità prima che raggiungano la produzione.

Rischio da mitigare

Le vulnerabilità a livello di codice che sfuggono alla rilevazione durante lo sviluppo creano debolezze di sicurezza persistenti che gli avversari sfruttano sistematicamente. Senza integrazione SAST completa:

  • Vulnerabilità di inserimento: Attacchi SQL injection, cross-site scripting (XSS), inserimento di comandi e errori di inserimento LDAP consentono agli utenti malintenzionati di modificare la logica dell'applicazione, estrarre dati sensibili o eseguire codice arbitrario.
  • Credenziali incorporate nel codice: Gli sviluppatori commettono inavvertitamente password, chiavi API, certificati e stringhe di connessione nei repository di codice sorgente, permettendo agli utenti malintenzionati accesso diretto a sistemi e dati di produzione.
  • Implementazioni crittografiche non sicure: Algoritmi di crittografia deboli (DES, MD5), chiavi di crittografia hardcoded, vettori di inizializzazione non appropriati o lunghezze di chiave insufficienti compromettere la riservatezza e l'integrità dei dati.
  • Overflow del buffer e danneggiamento della memoria: Le operazioni non sicure della memoria nelle applicazioni C/C++ permettono l'esecuzione arbitraria del codice, l'aumento dei privilegi e gli attacchi di Denial of Service.
  • Difetti della logica di business: Bypass dell'autenticazione, lacune di autorizzazione, race condition e la convalida insufficiente degli input consente l'escalation dei privilegi, le frodi e l'accesso non autorizzato.
  • Errori di configurazione dell'infrastruttura come codice (IaC): I manifesti Terraform, ARM o Kubernetes non sicuri distribuiscono un'infrastruttura vulnerabile con accesso eccessivamente permissivo, crittografia mancante o endpoint di gestione esposti.

In assenza di SAST automatizzato, le vulnerabilità si accumulano come debito tecnico, prolungano il tempo di permanenza e diventano costose da correggere in produzione.

MITRE ATT&CK

  • Accesso iniziale (TA0001): exploit dell'applicazione pubblica (T1190) sfruttando vulnerabilità di inserimento o bypass di autenticazione nel codice dell'applicazione.
  • Esecuzione (TA0002): sfruttamento per l'esecuzione client (T1203) sfruttando vulnerabilità lato client come XSS o deserializzazione non sicura.
  • Accesso alle credenziali (TA0006): credenziali dagli archivi password (T1555) che estraggono credenziali hardcoded dal codice sorgente, dai file di configurazione o dai file binari compilati.
  • Escalation dei privilegi (TA0004): sfruttamento di vulnerabilità per l'escalation dei privilegi (T1068) attraverso overflow del buffer o danneggiamenti della memoria per ottenere accesso con privilegi elevati.

DS-4.1: Implementare la pipeline SAST multi-scanner

I test completi di sicurezza delle applicazioni statici integrati in ogni compilazione forniscono il rilevamento anticipato delle vulnerabilità a livello di codice prima di raggiungere gli ambienti di produzione. Le applicazioni moderne usano linguaggi, framework e infrastrutture come codice che richiedono analizzatori specializzati, nessun singolo scanner rileva tutte le classi di vulnerabilità. Le strategie SAST a più livelli che combinano strumenti specializzati con l'esecuzione automatica e i controlli di qualità garantiscono una copertura completa fornendo agli sviluppatori un feedback immediato quando vengono rilevati problemi di sicurezza.

Implementare test di sicurezza automatizzati con questi componenti:

  • Implementare una strategia di analisi a più livelli: Incorporare test automatizzati di sicurezza delle applicazioni statiche in ogni compilazione per rilevare le vulnerabilità prima che il codice raggiunga l'ambiente di produzione. Implementare una strategia SAST a più livelli che combina più scanner specializzati senza un singolo strumento rileva tutte le classi di vulnerabilità, quindi una copertura completa richiede analizzatori specifici del linguaggio (Python, JavaScript, C/C++), scanner di infrastruttura come codice (Terraform, modelli ARM, manifesti Kubernetes), rilevamento dei segreti e analisi semantica del codice per vulnerabilità complesse del flusso di dati.

  • Configurare l'esecuzione automatica con gate di qualità: Configurare l'analisi SAST affinché venga eseguita automaticamente ad ogni commit e pull request, fornendo agli sviluppatori un feedback immediato sui problemi di sicurezza quando il contesto del codice è ancora fresco. Stabilire controlli di qualità basati su gravità che bloccano le operazioni di merge o distribuzioni quando vengono rilevate vulnerabilità critiche o con gravità elevata, impedendo al codice vulnerabile di avanzare attraverso la pipeline. Configurare gli scanner per restituire i risultati in formati standardizzati (SARIF) che consentono il rilevamento coerente delle vulnerabilità, la deduplicazione tra gli strumenti e l'integrazione con dashboard di sicurezza centralizzati.

  • Distribuire l'analisi dei segreti con la protezione push: Implementare l'analisi dei segreti specializzata con protezione push che impedisce agli sviluppatori di eseguire il commit di credenziali, chiavi API, certificati o token nei repository che intercettano i segreti in fase di commit anziché individuarli nelle verifiche di controllo settimane dopo. Supportare entrambi i modelli di segreto standard (chiavi AWS, token di Azure, stringhe di connessione del database) e modelli personalizzati specifici dell'organizzazione per i meccanismi di autenticazione proprietari. Quando vengono rilevati segreti, fornire indicazioni immediate sulla correzione, incluse le procedure di rotazione delle credenziali e alternative sicure.

  • Usare l'analisi semantica del codice per individuare vulnerabilità complesse: Distribuire strumenti di analisi del codice semantico come GitHub CodeQL che eseguono un'analisi approfondita del flusso di dati per identificare vulnerabilità complesse invisibili agli scanner corrispondenti ai criteri, ad esempio SQL injection tramite più chiamate di funzione, bypass di autenticazione nella logica di business o catene di deserializzazione non sicure. Creare query di sicurezza personalizzate in base ai framework dell'organizzazione, ai requisiti di sicurezza e ai modelli di vulnerabilità comuni identificati nelle retrospezioni sugli incidenti. Integrare i risultati SAST direttamente nei flussi di lavoro degli sviluppatori tramite commenti delle richieste pull con numeri di riga specifici, spiegazioni delle vulnerabilità e raccomandazioni di correzione.

  • Orchestrare con piattaforme unificate: Le piattaforme SAST unificate come Microsoft Security DevOps Extension possono orchestrare più scanner specializzati (AntiMalware, Bandit, BinSkim, Checkov, ESLint, Template Analyzer, Terrascan, Trivy) tramite una singola attività pipeline, standardizzando la gestione della configurazione e l'aggregazione dei risultati in ecosistemi di strumenti eterogenei.

Esempio di implementazione

Un provider SaaS ha subito un attacco SQL injection che espone centinaia di migliaia di record dei clienti. L'analisi post-evento imprevisto ha rivelato vulnerabilità estese a livello di codice, tra cui credenziali hardcoded e difetti di inserimento esistenti per mesi.

Sfida: Le revisioni manuali del codice hanno rilevato solo una piccola frazione di vulnerabilità. Gli sviluppatori non disponevano di formazione sulla sicurezza per identificare i difetti di inserimento e i punti deboli di crittografia. Nessuna analisi automatizzata prima del rilascio in produzione.

Approccio alla soluzione:

  • SAST multi-scanner: Implementata l'estensione DevOps di Microsoft Security con CodeQL, ESLint e Bandit offrendo una copertura completa tra linguaggi e tipi di vulnerabilità.
  • Protezione dei segreti: Implementazione di GitHub Advanced Security con l'analisi dei segreti e la protezione push che impedisce l'esposizione delle credenziali nei commit.
  • Analisi semantica:GitHub CodeQL configurato con query personalizzate per le vulnerabilità della logica di business e i modelli di sicurezza specifici del framework.
  • Controlli di sicurezza: Controlli della pipeline stabiliti in Azure Pipelines che bloccano la distribuzione di risultati con gravità elevata.

Risultato: Identificate e risolte rapidamente vulnerabilità estese. È stato impedito che i difetti critici di sicurezza andassero in produzione. Riduzione sostanziale del debito di sicurezza.

Livello di criticità

Indispensabile.

Mapping controlli

  • NIST SP 800-53 Rev.5: SA-11, RA-5, SI-2
  • PCI-DSS v4: 6.3.2, 6.4.1, 11.3.1
  • Controlli CIS v8.1: 16.3, 16.6
  • NIST CSF v2.0: PR.IP-2, DE.CM-4
  • ISO 27001:2022: A.8.25, A.8.29
  • SOC 2: CC7.1, CC7.2

DS-5: Integrare il test di sicurezza delle applicazioni dinamiche (DAST)

Principio di sicurezza

Implementare test di sicurezza dinamici completi in ambienti di pre-produzione tramite l'analisi della sicurezza dei contenitori per carichi di lavoro in contenitori, test di penetrazione automatizzati per applicazioni Web e API (Application Programming Interface) e test specializzati per l'autenticazione, l'autorizzazione e la gestione delle sessioni. La convalida del runtime identifica i punti deboli della configurazione e le vulnerabilità di integrazione che l'analisi statica non è in grado di rilevare.

Rischio da mitigare

Le vulnerabilità di runtime invisibili all'analisi statica creano lacune di sicurezza critiche che sfruttano gli avversari dopo la distribuzione delle applicazioni. Senza un DAST esaustivo:

  • Punti deboli della configurazione della distribuzione: provider di autenticazione configurati in modo errato, CORS troppo permissive, configurazioni TLS deboli o intestazioni di sicurezza mancanti (CSP, HSTS, X-Frame-Options) possono consentire attacchi che la revisione del codice non è in grado di rilevare.
  • Gap di sicurezza delle API: Le API REST e GraphQL con bypass di autenticazione, errori di autorizzazione, esposizione eccessiva dei dati, limitazione della frequenza mancante o riferimenti a oggetti diretti non sicuri (IDOR) consentono l'accesso non autorizzato e l'estrazione dei dati.
  • Bypass di autenticazione e autorizzazione: Difetti nella gestione delle sessioni, nei flussi di reimpostazione delle password, nell'implementazione dell'autenticazione a più fattori o nella logica di controllo degli accessi basato sui ruoli abilitano l'escalation dei privilegi e il takeover dell'account.
  • Vulnerabilità di gestione delle sessioni: I token di sessione prevedibili, l'insufficiente applicazione del timeout, le vulnerabilità di fissazione della sessione o l'assenza di revoca del token consentono il dirottamento di sessioni e il furto di credenziali.
  • Problemi di sicurezza specifici dell'ambiente: I punti di integrazione con database, code di messaggi, API esterne o servizi di terze parti introducono vulnerabilità di runtime invisibili nello sviluppo o nei test isolati.
  • Difetti della logica di business: Condizioni di corsa, vulnerabilità nella manipolazione dello stato, convalida dell'input insufficiente nei flussi di lavoro complessi, o problemi di integrità delle transazioni che consentono frodi e manipolazione dei dati.

DAST convalida il comportamento durante l'esecuzione, la configurazione dell'ambiente e la sicurezza dell'integrazione, offrendo una copertura che l'analisi statica non può fornire.

MITRE ATT&CK

  • Accesso iniziale (TA0001): exploit dell'applicazione esposta al pubblico (T1190) sfruttando i bypass di autenticazione, le vulnerabilità di iniezione o gli endpoint API non sicuri individuati tramite test di runtime.
  • Accesso alle credenziali (TA0006): forza bruta (T1110) che sfrutta l'assenza di limitazione del tasso, criteri di password deboli o token di sessione prevedibili rilevati durante DAST.
  • Escalation dei privilegi (TA0004): account validi (T1078) che ignorano le autorizzazioni o le vulnerabilità di manipolazione dei ruoli nelle applicazioni distribuite.
  • Raccolta (TA0009): dati provenienti da repository di informazioni (T1213) che estraggono dati sensibili tramite risposte API eccessive, attraversamento della directory o vulnerabilità di riferimento a oggetti diretti non sicuri.
  • Esfiltrazione (TA0010): esfiltrazione sul servizio Web (T1567) sfruttando i gap di sicurezza dell'API per estrarre i dati su larga scala senza rilevare.

DS-5.1: Implementare DAST automatizzato in pre-produzione

I test dinamici di sicurezza delle applicazioni convalidano i controlli di sicurezza nelle applicazioni in esecuzione, individuando le vulnerabilità di runtime che l'analisi statica non è in grado di rilevare. Mentre SAST esamina il codice sorgente, i test DAST hanno distribuito applicazioni con configurazioni simili alla produzione per identificare problemi specifici della distribuzione, tra cui errori di configurazione dell'autenticazione, errori di autorizzazione e lacune di sicurezza dell'integrazione che si manifestano solo negli ambienti operativi. Il DAST automatizzato nella pre-produzione garantisce la convalida della sicurezza prima dell'esposizione dei clienti durante il test di scenari di attacco realistici nei sistemi integrati.

Implementare la convalida della sicurezza in fase di esecuzione tramite queste funzionalità:

  • Integrare SAST con la convalida del runtime: Integrare l'analisi statica con test dinamici della sicurezza delle applicazioni che convalidano la sicurezza nelle applicazioni in esecuzione con configurazioni simili alla produzione. Mentre SAST identifica le vulnerabilità nel codice sorgente, DAST individua i problemi di runtime invisibili all'analisi statica: punti deboli della configurazione della distribuzione (provider di autenticazione non configurati correttamente, criteri CORS permissivi, intestazioni di sicurezza mancanti), errori di integrazione specifici dell'ambiente (sicurezza della connessione del database, autorizzazione API nei contesti distribuiti) e vulnerabilità della logica di business che si manifestano solo in condizioni operative realistiche.

  • Distribuire in ambienti di staging simili all'ambiente di produzione: Distribuire l'analisi DAST in ambienti di staging di pre-produzione che rispecchiano l'architettura di produzione, la topologia di rete, le dipendenze esterne e i parametri di configurazione. L'esecuzione automatizzata di DAST dovrebbe attivarsi al momento della distribuzione su staging, testando sistematicamente i flussi di autenticazione, i limiti di autorizzazione, la gestione delle sessioni, la convalida di input, la sicurezza delle API e la gestione degli errori sotto carichi e modelli d'uso realistici. Ciò verifica che i controlli di sicurezza funzionino correttamente quando sono integrati con sistemi esterni simili alla produzione (provider di identità, database, code di messaggi, API di terze parti).

  • Implementare il monitoraggio in fase di runtime per i container: Per i carichi di lavoro containerizzati, implementare un monitoraggio continuo della sicurezza in fase di runtime che combini la scansione delle immagini prima della distribuzione con l'analisi comportamentale dopo la distribuzione. Analizzare le immagini del contenitore per individuare vulnerabilità note prima della distribuzione, quindi monitorare l'esecuzione di contenitori per connessioni di rete anomale, l'esecuzione di processi non autorizzati, le modifiche al file system e i tentativi di escalation dei privilegi. Profilare il normale comportamento del carico di lavoro Kubernetes per rilevare le deviazioni che indicano la compromissione e valutare continuamente le configurazioni dei contenitori rispetto ai benchmark CIS e alle procedure consigliate per la sicurezza.

  • Concentrarsi sulle superfici di attacco ad alto rischio: Concentrare le attività DAST specializzate sulle superfici di attacco ad alto rischio: API REST e GraphQL (bypass dell'autenticazione di test, errori di autorizzazione, vulnerabilità di inserimento, esposizione eccessiva dei dati, riferimenti a oggetti diretti non sicuri), autenticazione e gestione delle sessioni (convalida della sicurezza dei token, applicazione del timeout, funzionalità di disconnessione, flussi di reimpostazione della password, autenticazione a più fattori) e flussi di lavoro della logica di business (test per race condition, manipolazione dello stato, problemi di integrità delle transazioni). Stabilire flussi di lavoro di correlazione SAST/DAST che combinano i risultati di entrambi gli approcci, assegnando priorità alle vulnerabilità confermate tramite analisi statiche e dinamiche come rischio più elevato.

  • Sfruttare le piattaforme integrate: Per gli ambienti in contenitori, Microsoft Defender per contenitori offre funzionalità integrate di valutazione della vulnerabilità del runtime, profilatura dei carichi di lavoro e rilevamento delle minacce durante tutto il ciclo di vita del contenitore.

Esempio di implementazione

Un'organizzazione di e-commerce ha individuato il bypass dell'autenticazione nell'API di pagamento che consente sconti non autorizzati. SAST ha perso il difetto di configurazione del runtime che si è manifestato solo negli ambienti distribuiti con provider di autenticazione esterni.

Sfida: SAST ha rilevato vulnerabilità del codice, ma non sono stati rilevati problemi di configurazione del runtime e errori di autorizzazione API. La configurazione della distribuzione di produzione differiva da quella di sviluppo, creando gap di sicurezza invisibili all'analisi statica.

Approccio alla soluzione:

  • Analisi DAST automatizzata:OWASP ZAP distribuito in ambienti di pre-produzione che testano le applicazioni distribuite con configurazioni simili alla produzione.
  • Protezione del runtime dei contenitori: Implementato Microsoft Defender per i contenitori per il monitoraggio della sicurezza durante il runtime e la valutazione delle vulnerabilità.
  • Test di sicurezza api: Configurazione di test api specializzati che convalidano l'autenticazione, l'autorizzazione e la convalida dei dati negli endpoint REST e GraphQL distribuiti.
  • Correlazione SAST/DAST: Creazione di flussi di lavoro di correlazione della vulnerabilità che combinano risultati statici e dinamici per la convalida completa della sicurezza.

Risultato: Vulnerabilità di runtime individuate perse da SAST, tra cui bypass di autenticazione e difetti di autorizzazione API. Impediti gli incidenti di sicurezza mediante rilevamento in pre-produzione.

Livello di criticità

Indispensabile.

Mapping controlli

  • NIST SP 800-53 Rev.5: SA-11, CA-8, RA-5
  • PCI-DSS v4: 6.4.2, 11.3.2
  • Controlli CIS v8.1: 16.7, 16.8
  • NIST CSF v2.0: DE.CM-4, PR.IP-12
  • ISO 27001:2022: A.8.29, A.8.30
  • SOC 2: CC7.1, CC7.3

DS-6: Proteggere il ciclo di vita del carico di lavoro

Criteri di Azure: Vedere Definizioni di criteri predefiniti di Azure: DS-6.

Principio di sicurezza

Implementare un'infrastruttura non modificabile con sicurezza completa delle immagini tramite registri di container e scansione di sicurezza per carichi di lavoro dei container, gestione delle immagini dorate e costruzione automatizzata per carichi di lavoro per macchine virtuali e scansione continua delle vulnerabilità con quarantena automatica. Verificare le firme crittografiche, mantenere immagini di base minime e applicare le baseline di sicurezza per tutto il ciclo di vita del carico di lavoro.

Rischio da mitigare

La gestione del ciclo di vita del carico di lavoro non sicura consente agli artefatti vulnerabili o compromessi di raggiungere la produzione, creando vettori di attacco persistenti che sfruttano sistematicamente gli avversari. Senza sicurezza completa del carico di lavoro:

  • Immagini di macchine virtuali di produzione vulnerabili: Le linee di base del sistema operativo senza patch o le immagini d'oro non configurate correttamente propagano i punti deboli in tutte le macchine virtuali distribuite.
  • Immagini di base vulnerabili senza patch: I contenitori basati sulle basi interessate da CVE (Log4Shell, Heartbleed, OpenSSL) espongono i carichi di lavoro allo sfruttamento e all'escape.
  • Artefatti vulnerabili non aggiornati: Le immagini e i pacchetti non scansionati accumulano le CVE, ampliando la superficie d'attacco.
  • Verifica dell'immagine insufficiente: La mancanza di firma crittografica e la convalida della provenienza consente agli avversari di sostituire immagini legittime con versioni compromesse contenenti backdoor o malware.
  • Superficie di attacco gonfia: Le immagini del contenitore contenenti pacchetti non necessari, strumenti di sviluppo o utilità di debug aumentano l'esposizione alle vulnerabilità e forniscono agli attaccanti strumenti di sfruttamento aggiuntivi.
  • Baseline di sicurezza mancanti: Le immagini di macchine virtuali e contenitori distribuite senza conformità del benchmark CIS, protezione avanzata o configurazione con privilegi minimi creano lacune sfruttabili in difesa avanzata.

Gli artefatti compromessi diventano vettori di attacco permanenti, aiutano lo spostamento laterale e appaiono legittimi per i difensori.

MITRE ATT&CK

  • Accesso iniziale (TA0001): exploit dell'applicazione pubblica (T1190) sfruttando le vulnerabilità senza patch nei contenitori di applicazioni o nei servizi Web.
  • Esecuzione (TA0002): distribuire un contenitore (T1610) che distribuisce contenitori dannosi che appaiono legittimi a causa di una verifica dell'immagine insufficiente.
  • Escalation dei privilegi (TA0004): salto all'host (T1611) sfruttando le vulnerabilità dei contenitori per evadere l'isolamento del contenitore e compromettere il sistema host.
  • Spostamento laterale (TA0008): sfruttamento dei servizi remoti (T1210) per eseguire il pivoting attraverso macchine virtuali o contenitori vulnerabili, distribuiti da immagini compromesse.

DS-6.1: Implementare la sicurezza delle immagini del contenitore

Le immagini dei contenitori e delle macchine virtuali rappresentano superfici di attacco critiche che richiedono controlli di sicurezza completi per tutto il ciclo di vita. Le immagini di base vulnerabili propagano i punti deboli a ogni istanza distribuita, amplificando l'impatto sull'infrastruttura. La gestione degli artefatti del carico di lavoro con lo stesso rigore di sicurezza del codice sorgente, tra cui l'analisi, la firma e l'archiviazione protetta, garantisce alle organizzazioni di distribuire solo immagini verificate, attendibili, impedendo agli utenti malintenzionati di sfruttare vulnerabilità note o sostituendo immagini dannose.

Proteggere gli artefatti del carico di lavoro tramite queste procedure:

  • Stabilire principi di infrastruttura immutabile: Considerare le immagini dei container e delle macchine virtuali come artefatti critici, che richiedono lo stesso rigore di sicurezza del codice sorgente, dato che le immagini base vulnerabili propagano le debolezze a ogni istanza distribuita. Stabilire principi dell'infrastruttura non modificabili in cui gli artefatti del carico di lavoro vengono compilati una sola volta, analizzati in modo completo, con firma crittografica e distribuiti senza modifiche per garantire coerenza e tracciabilità durante tutto il ciclo di vita.

  • Usare immagini di base minime con compilazioni a più fasi: Per i carichi di lavoro dei contenitori, implementare la sicurezza delle immagini a più livelli a partire da immagini di base minime che contengono solo componenti di runtime essenziali, riducendo notevolmente la superficie di attacco rispetto alle immagini complete del sistema operativo. Usare compilazioni a più fasi per separare le dipendenze di sviluppo dalle immagini di runtime: compilare e costruire immagini ricche di funzionalità, poi copiare solo gli artefatti finali in immagini di runtime minimali, eliminando strumenti di sviluppo, gestori di pacchetti e dipendenze di build che aumentano l'esposizione alle vulnerabilità e forniscono agli attaccanti strumenti per l'uso improprio.

  • Integrare l'analisi automatizzata con i criteri di quarantena: Integrare l'analisi automatica delle vulnerabilità nella pipeline di compilazione di immagini che analizza ogni immagine prima dell'archiviazione del Registro di sistema, verificando i database CVE completi e rielaborando continuamente le immagini archiviate man mano che vengono divulgate nuove vulnerabilità. Implementare criteri di quarantena automatizzati che impediscono alle immagini con vulnerabilità critiche o con gravità elevata di distribuzione, con flussi di lavoro di eccezione che richiedono l'approvazione del team di sicurezza e l'accettazione documentata dei rischi. Stabilire criteri di aggiornamento delle immagini di base con trigger di pipeline automatizzati quando vengono rilasciate patch di sicurezza, assicurando che le immagini non accumulino CVE nel tempo.

  • Applicare la firma e la verifica crittografiche: Applicare l'integrità delle immagini tramite la firma crittografica e la verifica in ogni fase delle immagini in fase di compilazione, verificare le firme prima della distribuzione e rifiutare automaticamente immagini non firmate o manomesse. In questo modo si evitano attacchi di sostituzione delle immagini in cui gli avversari sostituiscono immagini legittime con versioni compromesse contenenti backdoor. Archiviare immagini in registri contenitori protetti con controlli di accesso alla rete (endpoint privati, integrazione della rete virtuale), criteri di accesso basati sui ruoli che limitano chi può eseguire il push/pull delle immagini e la registrazione completa dei controlli di tutte le operazioni del Registro di sistema.

  • Gestire immagini d'oro con protezione avanzata per le macchine virtuali: Per i carichi di lavoro delle macchine virtuali, gestire repository di immagini di riferimento centralizzate con immagini di base conformi al benchmark CIS che subiscono regolari patch di sicurezza e convalida della conformità. Implementare pipeline di creazione automatica di immagini che incorporano gli aggiornamenti della sicurezza, rimuovere i servizi non necessari, applicare configurazioni con privilegi minimi e generare immagini aggiornate in base alle pianificazioni definite anziché applicare patch ai sistemi in esecuzione.

  • Sfruttare le piattaforme di sicurezza integrate: Soluzioni come Registro Azure Container con l'integrazione di Microsoft Defender per contenitori offrono analisi automatizzate, flussi di lavoro di quarantena, attendibilità del contenuto e replica in più aree con criteri di sicurezza coerenti.

Esempio di implementazione

Un'organizzazione logistica ha distribuito un'applicazione contenitore con un'immagine di base senza patch contenente vulnerabilità critica per l'esecuzione di codice remoto. Gli utenti malintenzionati hanno sfruttato la vulnerabilità poco dopo la distribuzione, compromettendo i dati di spedizione.

Sfida: Numerose immagini del contenitore senza analisi delle vulnerabilità. Le immagini compilate mesi fa accumularono molte CVE, incluse le vulnerabilità critiche. Nessuna verifica ha impedito la sostituzione di immagini dannose.

Approccio alla soluzione:

  • Sicurezza del registro dei contenitori: Implementato Azure Container Registry con l'analisi delle vulnerabilità che mette in quarantena le immagini con CVE a gravità elevata prima della distribuzione.
  • Immagini di vm con protezione avanzata: Raccolta di immagini condivise di Azure con immagini vm conformi al benchmark CIS per carichi di lavoro regolamentati.
  • Protezione di runtime: Configurato Microsoft Defender per contenitori per il rilevamento continuo delle minacce e il monitoraggio delle variazioni.
  • Integrità artefatto: La firma crittografica e la verifica stabilite garantiscono l'autenticità dell'immagine durante tutto il ciclo di vita.

Risultato: Bloccate dalla distribuzione di produzione immagini vulnerabili. Riduzione drastica delle CVE dei container per immagine. È stato impedito l'attacco di sostituzione delle immagini tramite la verifica della firma.

Livello di criticità

Indispensabile.

Mapping controlli

  • NIST SP 800-53 Rev.5: CM-2, CM-3, SI-2, SI-7, RA-5
  • PCI-DSS v4: 6.2.4, 6.3.3, 11.3.1
  • Controlli CIS v8.1: 4.1, 7.3, 7.4
  • NIST CSF v2.0: PR.IP-1, PR.IP-3, DE.CM-8
  • ISO 27001:2022: A.8.9, A.8.31, A.8.32
  • SOC 2: CC7.2, CC8.1

DS-7: Implementare la registrazione e il monitoraggio di DevOps

Principio di sicurezza

Implementare la registrazione completa delle attività DevOps tramite il flusso di controllo con l'integrazione per piattaforme SIEM (Security Information and Event Management) centralizzate per l'analisi della sicurezza, il rilevamento delle minacce in tempo reale e la risposta automatica. Stabilire analisi comportamentali, rilevamento anomalie e metriche di sicurezza per consentire una risposta rapida agli eventi imprevisti e mantenere i percorsi di controllo della conformità.

Rischio da mitigare

Una registrazione e un monitoraggio DevOps insufficienti creano punti ciechi critici che gli avversari sfruttano per operare senza essere rilevati, mantenere una presenza persistente ed esfiltrare codice sensibile o credenziali. Senza visibilità completa:

  • Compromissioni della pipeline non rilevate: Gli utenti malintenzionati modificano le pipeline CI/CD per inserire codice dannoso, esfiltrare segreti o stabilire backdoor senza attivare avvisi a causa della registrazione di controllo assente o insufficiente.
  • Minacce Insider che modificano codice o infrastruttura: Gli utenti malintenzionati o gli account compromessi apportano modifiche non autorizzate al codice sorgente, alle definizioni dell'infrastruttura o alle configurazioni di distribuzione senza rilevamento.
  • Mancanza di audit trail completi: L'assenza di log attività dettagliati impedisce l'analisi forense, la valutazione dell'impatto e l'analisi della causa radice quando si verificano eventi imprevisti di sicurezza che causano tempi di attesa prolungati e un aumento dell'impatto sulle violazioni.
  • Risposta ritardata agli eventi imprevisti: Il tempo medio di rilevamento (MTTD) si estende da ore a settimane quando i team di sicurezza non dispongono di avvisi in tempo reale, rilevamento anomalie e correlazione automatica degli eventi di sicurezza DevOps.
  • Errori di controllo di conformità: I requisiti normativi (SOX, PCI-DSS, HIPAA, ISO 27001) che mandano audit trail completi, rilevamento delle modifiche e registrazione degli accessi non possono essere soddisfatti senza il monitoraggio centralizzato di DevOps.
  • Cecità di escalation dei privilegi: L'elevazione non autorizzata dei privilegi, la creazione di account backdoor o la modifica dei controlli di accesso procede senza essere rilevata in assenza di analisi comportamentale e monitoraggio dei privilegi.

Le lacune di registrazione nascondono modifiche alle pipeline dannose, l'escalation dei privilegi e i tentativi continui di accesso nei percorsi di sviluppo con privilegi elevati.

MITRE ATT&CK

  • Evasione della difesa (TA0005): compromissione delle difese (T1562) disabilitare la registrazione di controllo, passaggi di scansione della sicurezza, o agenti di monitoraggio per operare nelle zone d'ombra, e rimozione degli indicatori (T1070) cancellare i registri di controllo o la cronologia di esecuzione della pipeline per nascondere attività dannose.
  • Persistenza (TA0003): manipolazione dell'account (T1098) creazione di entità servizio aggiuntive, token di accesso personale o chiavi SSH senza rilevamento.
  • Raccolta (TA0009): dati provenienti da repository di informazioni (T1213) che esfiltrano codice sorgente, segreti o proprietà intellettuale tramite l'accesso alla pipeline.
  • Accesso alle credenziali (TA0006): credenziali non protette (T1552) che raccolgono segreti esposti dai log della pipeline o dalla cronologia di esecuzione.

DS-7.1: Implementare la registrazione di controllo per le piattaforme DevOps

Le piattaforme DevOps con accesso privilegiato all'infrastruttura di produzione e al codice sorgente sensibile richiedono un monitoraggio completo della sicurezza per rilevare le attività antagoniste e le minacce interne. I gap di registrazione dei controlli consentono agli attori malintenzionati di operare non rilevati per periodi prolungati, mentre l'aggregazione centralizzata dei log consente la correlazione con dati di telemetria di sicurezza più ampi rivelando catene di attacco sofisticate. L'analisi comportamentale in tempo reale identifica modelli sospetti invisibili in eventi isolati, trasformando i dati di controllo non elaborati in intelligence per la sicurezza pratica.

Stabilire un monitoraggio completo della sicurezza devOps tramite queste funzionalità:

  • Acquisire attività complete relative alla sicurezza: Stabilire una registrazione di controllo completa che acquisisca tutte le attività DevOps rilevanti per la sicurezza: eventi di autenticazione e autorizzazione utente, commit del codice sorgente e operazioni di ramo, creazione e modifica della pipeline, esecuzioni di distribuzione, accesso segreto, modifiche delle autorizzazioni, creazione dell'entità servizio e azioni amministrative. Le piattaforme DevOps mantengono l'accesso con privilegi all'infrastruttura di produzione e le lacune di registrazione del codice sensibili consentono agli avversari e ai partecipanti malintenzionati di operare non rilevati per periodi prolungati.

  • Inoltrare i log a siem centralizzati in tempo reale: Inoltrare i log di controllo in tempo reale alle piattaforme SIEM centralizzate anziché basarsi sulla conservazione nativa della piattaforma DevOps (in genere 90 giorni), abilitando analisi forensi a lungo termine, report di conformità e correlazione con gli eventi di sicurezza di altri sistemi. Trasmettere i log ai centri operativi di sicurezza tramite protocolli standardizzati (/hub eventi di Azure, syslog) in formati strutturati (JSON) che consentono l'analisi, l'analisi e gli avvisi automatizzati senza revisione manuale dei log.

  • Distribuire l'analisi comportamentale e il rilevamento anomalie: Implementare l'analisi comportamentale e il rilevamento anomalie nei dati di controllo DevOps per identificare modelli sospetti invisibili nei singoli eventi: modifiche della pipeline dopo ore, accesso insolito ai repository sensibili, escalation rapida dei privilegi, creazione di entità servizio seguita da distribuzioni sospette, esecuzioni di pipeline da posizioni impreviste o modelli anomali di accesso segreto. Stabilire profili di comportamento di base per utenti e servizi, avvisando su deviazioni statisticamente significative che possono indicare minacce interne o compromesse.

  • Configurare gli avvisi automatizzati per le attività ad alto rischio: Configurare gli avvisi automatizzati per le attività ad alto rischio con una notifica immediata ai team di sicurezza: errori di distribuzione di produzione, modifiche delle pipeline nei rami protetti, creazione di nuove entità servizio, eventi di elevazione delle autorizzazioni, passaggi di analisi della sicurezza disabilitati, modifiche alla configurazione di inoltro dei log di controllo o tentativi di accesso ai segreti da pipeline non autorizzate. Implementare l'escalation basata sulla gravità assicurando che gli avvisi critici raggiungano immediatamente le operazioni di sicurezza mentre gli eventi di routine vengono raggruppati per l'analisi.

  • Eseguire l'integrazione con dati di telemetria di sicurezza più ampi: Integrare i log di controllo devOps con dati di telemetria di sicurezza più ampi nelle piattaforme SIEM per la correlazione con il rilevamento degli endpoint, la sicurezza di rete, gli eventi di identità e i feed di intelligence sulle minacce. In questo modo è possibile rilevare catene di attacco sofisticate in cui la compromissione di DevOps è un passaggio in più fasi delle operazioni, ad esempio correlando le credenziali di phishing con le successive modifiche alla pipeline e un provisioning insolito di risorse cloud.

  • Sfruttare le piattaforme SIEM integrate: Piattaforme come Azure DevOps Audit Streaming con l'integrazione di Microsoft Sentinel forniscono l'inoltro dei log in tempo reale, regole di rilevamento predefinite per le minacce DevOps, cartelle di lavoro di sicurezza per l'analisi e orchestrazione automatica delle risposte.

Esempio di implementazione

Un'organizzazione manifatturiera ha scoperto una minaccia interna quando un ex appaltatore ha modificato la pipeline CI/CD, inserendo un codice backdoor nell'applicazione di produzione. L'incidente è rimasto non rilevato per mesi a causa di un logging di audit insufficiente.

Sfida: Nessuna registrazione centralizzata delle attività DevOps. Le modifiche alla pipeline e le modifiche di accesso con privilegi non sono state monitorate. Indagine forense ostacolata dalla mancanza di audit trail. Controllo di conformità non riuscito a causa di un rilevamento delle modifiche insufficiente.

Approccio alla soluzione:

  • Registrazione di controllo centralizzata: Inoltro abilitato degli eventi di streaming di controllo di Azure DevOps a Microsoft Sentinel per l'analisi della sicurezza e la conservazione a lungo termine.
  • Analisi comportamentale: È stato implementato il rilevamento anomalie che identifica modelli di accesso insoliti, modifiche della pipeline dopo l'orario di lavoro ed escalation dei privilegi che indicano una minaccia interna.
  • Avvisi automatizzati: Avvisi configurati per attività sospette, incluse le implementazioni di produzione non autorizzate e il routing relativo alla creazione dei principali di servizio alle operazioni di sicurezza.
  • Report di conformità: È stata creata una generazione automatizzata di audit trail che soddisfa i requisiti normativi con il rilevamento completo delle modifiche.

Risultato: Rilevata e impedita rapidamente le successive modifiche alle pipeline non autorizzate. Riduzione drastica del tempo di analisi degli eventi imprevisti con audit trail completi. È stata ottenuta la conformità con la gestione delle modifiche documentata.

Livello di criticità

Dovrebbe avere.

Mapping controlli

  • NIST SP 800-53 Rev.5: AU-2, AU-3, AU-6, AU-12, SI-4
  • PCI-DSS v4: 10.2.1, 10.2.2, 10.3.4
  • Controlli CIS v8.1: 8.2 , 8.5, 8.11
  • NIST CSF v2.0: DE.CM-1, DE.CM-7, RS.AN-1
  • ISO 27001:2022: A.8.15, A.8.16
  • SOC 2: CC7.2, CC7.3
  • Last updated on