Dimenticate le oscure classi di bug: alcune delle vulnerabilità più subdole si nascondono in bella vista.
Si tratta di problemi di sicurezza di tipo "by-design", ossia di vulnerabilità intrinseche alla funzionalità di un sistema. Spesso si tratta di "stranezze" ben note del sistema, ma il loro impatto è poco esplorato. Mentre le vulnerabilità tradizionali richiedono la correzione di una riga di codice, questi problemi di progettazione richiedono spesso un ripensamento completo del sistema e una revisione totale della sua funzionalità.
Quando le funzionalità dei servizi cloud si discostano dalle norme del settore o dalle aspettative dei clienti, il "bug" descritto potrebbe essere intrinseco alla loro progettazione, ma può avere profonde implicazioni per la sicurezza.
Questo post approfondisce queste vulnerabilità cloud , spesso strutturali e di grande impatto, e spiega perché la correzione dei bug di sicurezza by-design richiede più di una semplice patch.
Abuso di funzionalità e vulnerabilità di progettazione insicure nella sicurezza Cloud
Definiamo per un attimo i contorni delle vulnerabilità Insecure-by-Design contrapponendole al Feature Abuse, ovvero l'abuso intenzionale di una funzionalità, un altro problema di sicurezza comune nel cloud.
Abuso di funzionalità: un rischio riconosciuto negli ambienti Cloud
L'abuso di funzionalità descrive un attore che utilizza una funzionalità cloud per perseguire un obiettivo dannoso. Non indica una vulnerabilità o una falla; rappresenta invece l'intento malvagio di utilizzare una funzionalità cloud legittima.
Evidenziamo la funzionalità standard dei sistemi IAM che consente di generare credenziali per un utente diverso da sé. Questa funzionalità 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. Al contrario, il settore lavora per prevenire e rilevare l'abuso di questa funzionalità con i controlli di mitigazione disponibili.
Insecure-by-Design - Una classe di vulnerabilità Cloud
Le aspettative e le norme del settore si estendono ai controlli di sicurezza che circondano le funzionalità cloud. Le vulnerabilità insicure per progettazione possono includere un controllo insufficiente da parte del cloud provider.
Nello scenario di generazione di credenziali descritto sopra, i consumatori del servizio si aspetterebbero controlli di autorizzazione prima di emettere credenziali e registrare tali eventi. L'assenza di questi controlli esporrebbe i clienti a rischi significativi, indicando un difetto di progettazione del servizio.
Un esempio più tangibile di vulnerabilità insecure-by-design si è verificato di recente all'interno del servizio DocumentAI di Google. Un utente di Document AI poteva spostare gli oggetti di Cloud Storage 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 notevole deviazione dai principi di progettazione sicura.
Vulnerabilità Insecure-by-Design e responsabilità condivisa
Come possiamo vedere, alcuni dei rischi di sicurezza più insidiosi sono insiti direttamente nella progettazione di un sistema. Questi difetti di Insecure-by-design diventano evidenti quando la funzionalità di un servizio o i controlli disponibili si discostano dalle norme stabilite e dalle aspettative dei clienti.
I difetti di progettazione non sicuri possono essere particolarmente frustranti nel cloud, dove la prevenzione dell'abuso del servizio è responsabilità dei clienti. Tuttavia, grazie alla delimitazione dei compiti nel modello di responsabilità condivisa, il fornitore di servizi è responsabile della disponibilità dei controlli necessari, della documentazione accurata e della formazione per implementare un servizio in modo sicuro.
Mitigare l'impatto delle vulnerabilità Insecure-by-Design nei servizi Cloud
La tradizionale correzione delle vulnerabilità spesso prevede un approccio semplice: identificare il codice difettoso, applicare una patch e distribuire l'aggiornamento. Ma questa mentalità "aggiusta e dimentica" non è all'altezza quando si tratta di vulnerabilità insicure per progettazione nei servizi cloud . Perché? Perché due caratteristiche distinguono queste vulnerabilità da quelle classiche di 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". La disabilitazione o la modifica significativa della funzionalità potrebbe interrompere innumerevoli carichi di lavoro.
- Con le API sempre disponibili, le funzionalità con potenziale di abuso non riguardano solo coloro che sfruttano 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 "riparazione" del servizio limita le opzioni per un'efficace riduzione del rischio. Chi si concentra sulla sicurezza cloud deve invece adottare una strategia più olistica. Ciò comporta l'implementazione di controlli preventivi e investigativi per mitigare i rischi, esplorando al contempo potenziali soluzioni a lungo termine per il difetto di progettazione sottostante. Uno strumento potente di questa strategia è l'uso dei guardrail.
Controlli di mitigazione: Guardrail
Nella sicurezza cloud , i guardrail sono controlli preventivi che applicano criteri e standard di sicurezza nell'ambiente cloud di un'organizzazione. Agiscono come paraurti lungo una pista da bowling, garantendo agli amministratori della sicurezza che l'utilizzo non si allontani troppo da uno schema prescritto.
La fornitura di guardrail preconfigurati può contribuire a mitigare le vulnerabilità cloud . Sono particolarmente utili per disattivare o eliminare completamente i comportamenti indesiderati. Tuttavia, l'efficacia dei guardrail diminuisce quando le funzionalità non sicure sono profondamente integrate nei processi critici. In questi casi, bloccare l'accesso alla funzione potrebbe non essere fattibile.
Controlli di mitigazione: Rilevamento e risposta
I controlli preventivi come i guardrail sono preziosi, ma non sempre sono sufficienti. L'implementazione può essere complessa e spesso sono necessarie eccezioni per soddisfare casi d'uso legittimi. Inoltre, per aiutare i clienti che già si affidano a funzionalità non sicure, non bastano i guardrail e i controlli preventivi.
Ecco perché il rilevamento e la creazione di una risposta agile sono spesso le attività di rimedio più importanti quando vengono identificate funzionalità non sicure.
Quando si considerano il rilevamento e la risposta come controlli di mitigazione delle vulnerabilità cloud , occorre porsi queste domande:
- I clienti ricevono un segnale ad alta fedeltà del comportamento illecito o sono necessari ulteriori registri?
- I registri sono abilitati per impostazione predefinita o il cliente deve essere avvisato per consentire la registrazione aggiuntiva.
- È possibile agire rapidamente sui risultati del rilevamento per ridurre ed eliminare i danni?
Eliminare le funzionalità Cloud insicure: Il lungo addio
L'introduzione di funzionalità insicure per progettazione 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 sui carichi di lavoro dei prodotti e dei clienti.
Sebbene sia spesso possibile rimuovere o risolvere queste vulnerabilità, soprattutto con un approccio graduale e l'introduzione di alternative più sicure, il processo è raramente rapido. Ecco perché i guardrail e i controlli investigativi sono fondamentali. Agiscono come bende molto necessarie, facendo guadagnare alle organizzazioni e ai loro clienti tempo prezioso per abbandonare le funzionalità insicure senza interrompere i processi aziendali.
Individuare gli abusi e implementare le protezioni:
- Date ai vostri team di sviluppo il tempo necessario per abbandonare le funzionalità insicure in modo ordinato, utilizzando le due leve dei controlli investigativi e preventivi.
Funzionalità Sunset:
- 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 incriminate.
Approccio del destino condiviso alla bonifica delle vulnerabilità Cloud
In definitiva, affrontare le vulnerabilità insecure-by-design richiede un approccio condiviso. I fornitori di Cloud e i loro clienti devono lavorare insieme, riconoscendo la natura intrecciata delle loro responsabilità.
I fornitori devono essere trasparenti quando i controlli di sicurezza non sono all'altezza delle aspettative e creano vulnerabilità insicure per progettazione. I clienti, a loro volta, devono sfruttare gli strumenti disponibili per prevenire e rilevare l'abuso delle funzionalità e allontanare i loro ambienti da modelli insicuri e tradizionali.
Questo approccio collaborativo contribuirà a garantire che il cloud continui a evolversi in un sistema più resiliente e sicuro per progettazione.