Dimenticate le classi di bug oscure: alcune delle vulnerabilità più subdole si nascondono in bella vista.
Si tratta di problemi di sicurezza intrinseci, ovvero vulnerabilità inerenti alle funzionalità di un sistema. Spesso possono essere "stranezze" ben note del sistema, ma il loro impatto complessivo è poco studiato. Mentre le vulnerabilità tradizionali richiedono correzioni del codice voce per voce, questi problemi intrinseci richiedono spesso un ripensamento completo del sistema e una revisione totale delle sue funzionalità.
Quando la funzionalità cloud si discosta dagli standard del settore o dalle aspettative dei clienti, il "bug" descritto potrebbe essere intrinseco al suo design, ma può avere profonde implicazioni per la sicurezza.
Questo post approfondisce queste cloud significative, spesso strutturali, esplorando il motivo per cui la correzione dei bug di sicurezza intrinseci richiede più di una semplice patch.
Abuso delle funzionalità contro vulnerabilità intrinseche nella Cloud
Prendiamoci un momento per definire i confini delle vulnerabilità Insecure-by-Design contrapponendole al Feature Abuse, ovvero l'uso improprio intenzionale di una funzionalità, un altro problema di sicurezza comune nel cloud.
Abuso delle funzionalità: un rischio riconosciuto negli Cloud
L'abuso delle funzionalità descrive un attore che utilizza una cloud per perseguire uno scopo dannoso. Non indica una vulnerabilità o un difetto, ma rappresenta piuttosto l'intento malevolo che sta dietro all'uso cloud una cloud legittima.
Evidenziamo la funzionalità standard dei sistemi IAM che consente di generare credenziali per un utente diverso da sé stessi. Questa capacità definisce il movimento laterale (e probabilmente l'escalation dei privilegi) con il rischio riconosciuto di un uso improprio intenzionale. Tuttavia, non esiste alcuna vulnerabilità in un sistema IAM che consenta a un utente di generare credenziali per un altro. L'industria lavora invece per prevenire e rilevare l'abuso di questa funzione con i controlli di mitigazione disponibili.
Insecure-by Design - Un corso Cloud
Le aspettative e gli standard del settore si estendono ai controlli di sicurezza relativi alle funzionalità cloud. Le vulnerabilità insite nella progettazione possono includere un controllo insufficiente da parte del cloud .
Nello scenario di generazione delle credenziali sopra descritto, gli utenti del servizio si aspetterebbero che venissero effettuati controlli di autorizzazione prima dell'emissione delle credenziali e della registrazione di tali eventi. L'assenza di tali controlli esporrebbe i clienti a rischi significativi, indicando un difetto di progettazione del servizio.
Un esempio più concreto di vulnerabilità insita nel design si è verificato di recente all'interno del servizio DocumentAI di Google. Un utente di Document AI poteva spostare oggetti Cloud al di fuori del progetto utilizzando i privilegi dell'agente del servizio DocumentAI senza che il sistema IAM verificasse che l'utente finale avesse accesso agli oggetti.
La mancanza dei controlli di autorizzazione previsti rappresentava una deviazione considerevole dai principi di progettazione sicura.
Vulnerabilità insicure per progettazione e responsabilità condivisa
Come possiamo vedere, alcuni dei rischi più insidiosi per la sicurezza sono insiti direttamente nella progettazione di un sistema. Questi difetti di sicurezza intrinseci diventano evidenti quando le funzionalità di un servizio o i controlli disponibili si discostano dalle norme stabilite e dalle aspettative dei clienti.
I difetti di sicurezza intrinseci possono essere particolarmente frustranti nel cloud, dove la prevenzione degli abusi del servizio è responsabilità dei clienti. Tuttavia, in base alla ripartizione dei compiti nel modello di responsabilità condivisa, il fornitore del servizio è responsabile di mettere a disposizione i controlli necessari, fornire una documentazione accurata e istruire gli utenti sull'implementazione sicura del servizio.
Mitigare l'impatto delle vulnerabilità insite nella progettazione Cloud
La risoluzione tradizionale delle vulnerabilità spesso prevede un approccio diretto: identificare il codice difettoso, applicare la patch e distribuire l'aggiornamento. Tuttavia, questa mentalità del "risolvi e dimentica" non è sufficiente quando si tratta di vulnerabilità insicure per definizione nei cloud . Perché? Perché due caratteristiche distinguono queste vulnerabilità dalle vulnerabilità classiche presenti in un pacchetto software.
- Queste vulnerabilità sono spesso profondamente intrecciate con le funzionalità del servizio o addirittura ne costituiscono i principi fondamentali, rendendo impraticabile una semplice "correzione". Disabilitare o alterare in modo significativo la funzionalità potrebbe interrompere innumerevoli carichi di lavoro.
- Con API sempre disponibili, le funzionalità potenzialmente soggette ad abuso non riguardano solo coloro che utilizzano il servizio, ma tutti i clienti, indipendentemente dal fatto che utilizzino o meno l'API.
Una mentalità a somma zero che si concentra esclusivamente sulla "correzione" del servizio limita le opzioni per una riduzione efficace del rischio. Chi si occupa cloud ha invece bisogno di una strategia più olistica. Ciò comporta l'implementazione di controlli preventivi e di rilevamento per mitigare i rischi, esplorando al contempo potenziali soluzioni a lungo termine per il difetto di progettazione sottostante. Uno strumento potente in questa strategia è l'uso delle barriere di protezione.
Controlli di mitigazione: guardrail
Nella cloud , i guardrail sono controlli preventivi che applicano le politiche e gli standard di sicurezza cloud di un'organizzazione. Funzionano come i paracolpi lungo una pista da bowling, garantendo agli amministratori della sicurezza che l'utilizzo non si discosti troppo da un modello prestabilito.
Fornire protezioni predefinite può aiutare a mitigare cloud . Sono particolarmente utili per disattivare o rimuovere completamente comportamenti indesiderati. Tuttavia, l'efficacia delle protezioni diminuisce quando le funzionalità non sicure sono profondamente integrate nei processi critici. In questi casi, bloccare l'accesso alla funzionalità potrebbe non essere fattibile.
Controlli di mitigazione: rilevamento e risposta
Sebbene i controlli preventivi come le barriere di protezione siano preziosi, non sempre sono sufficienti. La loro implementazione può essere complessa e spesso sono necessarie delle eccezioni per soddisfare casi d'uso legittimi. Inoltre, per aiutare i clienti che già fanno affidamento su funzionalità non sicure, sono necessari più delle barriere di protezione e dei controlli preventivi.
Ecco perché il rilevamento e la creazione di una risposta agile sono spesso le attività di correzione più efficaci quando viene identificata una funzionalità non sicura.
Quando si considerano il rilevamento e la risposta come controlli di mitigazione cloud , ponetevi queste domande:
- I clienti ricevono un segnale ad alta fedeltà del comportamento scorretto o sono necessari ulteriori registri?
- I log sono abilitati di default o è necessario avvisare il cliente per consentire la registrazione aggiuntiva?
- È possibile agire rapidamente in base al risultato del rilevamento per ridurre e rimuovere i danni?
Cloud non sicura in fase di dismissione: il lungo addio
L'introduzione di funzionalità insicure per definizione con potenziale di abuso può rivelarsi costosa per i fornitori di servizi. Una volta integrate nei flussi di lavoro dei clienti, queste funzionalità possono essere difficili da rimuovere o modificare a causa delle dipendenze a valle e delle ipotesi relative ai carichi di lavoro dei prodotti e dei clienti.
Sebbene spesso sia possibile rimuovere o correggere queste vulnerabilità, soprattutto con un approccio graduale e introducendo alternative più sicure, il processo raramente è rapido. Ecco perché le misure di protezione e i controlli di rilevamento sono fondamentali. Fungono da cerotti indispensabili, consentendo alle organizzazioni e ai loro clienti di guadagnare tempo prezioso per abbandonare le funzionalità non sicure senza interrompere i processi aziendali.
Rilevare gli abusi e implementare misure di protezione:
- Concedete ai vostri team di sviluppo il tempo necessario per abbandonare in modo ordinato le funzionalità non sicure utilizzando i due strumenti dei controlli investigativi e preventivi.
Funzionalità tramonto:
- Migrare i carichi di lavoro esistenti che dipendono da funzionalità non sicure verso modelli più sicuri. Interrompere l'uso delle funzionalità vulnerabili e infine eliminare le API non conformi.
Approccio condiviso alla risoluzione Cloud
In definitiva, affrontare le vulnerabilità insite nel design richiede un approccio basato sulla condivisione delle responsabilità. Cloud e i loro clienti devono collaborare, riconoscendo la natura intrecciata delle loro responsabilità.
I fornitori devono essere trasparenti quando i controlli di sicurezza non soddisfano le aspettative e creano vulnerabilità intrinseche. I clienti, a loro volta, devono sfruttare gli strumenti disponibili per prevenire e rilevare gli abusi delle funzionalità e allontanare i propri ambienti dai modelli legacy non sicuri.
Questo approccio collaborativo contribuirà a garantire che il cloud a evolversi in un sistema più resiliente e sicuro fin dalla progettazione.