Le configurazioni errate di Schrödinger

È giovedì pomeriggio e Lei si prepara a uscire dal lavoro un po' prima perché… può farlo. Ma proprio allora quel fastidioso Messaggero di Notifiche (noto anche come Slack) fa comparire un nuovo messaggio nel Suo canale degli avvisi di sicurezza:

Accidenti. Qualcuno ha appena reso pubblico lo snapshot di un volume di archiviazione. Si tratta di un attacco? Di un errore? Di qualcuno che semplicemente non conosce le policy?

Le configurazioni errate hanno tre stati di esistenza

È un fenomeno che ho iniziato a chiamare configurazioni errate di Schröedinger poiché ho la cattiva abitudine di ricorrere ai principi della meccanica quantistica per spiegare la sicurezza informatica. Sarei sorpreso se non conoscesse già il gatto di Schröedinger, il celebre esperimento mentale con cui Erwin Shröedinger illustrò ad Albert Einstein il paradosso della sovrapposizione quantistica. In estrema sintesi: se si chiude un gatto in una scatola con un veleno attivato dal decadimento radioattivo, il gatto non è né vivo né morto, e si trova quindi in uno stato in cui è vivo E morto allo stesso tempo, finché non si apre la scatola per verificare.

Sì, è assurdo, ed è proprio questo il punto. Soprattutto per chi, come noi, ha gatti che NON AMANO AFFATTO RESTARE CHIUSI NELLE SCATOLE. Anche se potrei scrivere un'intera serie di articoli sui gatti che si infilano da soli nelle scatole ma si arrabbiano moltissimo se ce li mettete voi e… ma sto divagando.

Torniamo alla sicurezza del cloud. Il concetto fondamentale alla base dell'esperimento mentale è che qualcosa esiste in più stati simultanei finché non lo si osserva, e che l'atto stesso dell'osservazione impone una risposta. Sto ovviamente forzando e semplificando per i miei scopi, quindi chi di voi ha una formazione in fisica eviti di inviarmi email indignate.

La versione cloud di questo concetto è che qualsiasi configurazione errata esiste in uno stato in cui è al tempo stesso un attacco, un errore o una violazione delle policy, finché non si indaga e non se ne determina la causa.

Vi sono 5 caratteristiche del cloud che avvalorano questo concetto:

• I team cloud/di sviluppo tendono ad avere maggiore autonomia nella gestione diretta della propria infrastruttura cloud.
• Il piano di gestione del cloud è accessibile via Internet.
• La fonte più comune (oggi) degli attacchi al cloud sono le credenziali rubate.
• Molte configurazioni errate creano stati identici alle azioni di un attaccante (ad esempio rendere pubblico uno snapshot).
• È facile creare accidentalmente una configurazione errata e, a volte, la si crea intenzionalmente per soddisfare un'esigenza, senza che chi compie l'azione si renda conto che si tratta di un problema di sicurezza.

Questo concetto vale anche nell'infrastruttura tradizionale, seppur in misura molto minore, poiché i team dispongono di minore autonomia. Di norma, chi sviluppa un'applicazione non può modificare direttamente le regole del firewall e le tabelle di routing. Nel cloud è invece piuttosto comune, almeno in alcuni ambienti.

Presumere un attacco fino a prova contraria

Uno dei principi più importanti della risposta agli incidenti nel cloud è che le configurazioni errate vanno assolutamente trattate come eventi di sicurezza, presumendo che siano attacchi fino a prova contraria.

Si tratta di un cambio di mentalità, perché la sicurezza è abituata a ragionare in termini di vulnerabilità e superficie di attacco, elementi che però consideriamo oggetto di scansioni periodiche e, in larga misura, problemi da correggere. La mia proposta è che nel cloud computing le configurazioni errate rilevate vengano elevate allo stesso livello di un avviso IDS o EDR. Non sono semplici problemi di conformità: sono potenziali indicatori di compromissione.

E no, questo non vale per ogni configurazione errata in ogni ambiente. Dobbiamo filtrare e stabilire delle priorità. Meglio ancora, dobbiamo comunicare, perché di solito il modo più semplice per capire se una configurazione errata è un attacco malevolo consiste semplicemente nel chiedere a chi ha effettuato la modifica se intendeva farlo.

Dovendo sintetizzare i concetti per i corsi di formazione, ho individuato tre fonti principali di telemetria di sicurezza:

• Log
• Eventi del provider cloud (ad esempio gli eventi di Security Hub)
• Configurazioni errate del cloud, che possono provenire dal Suo strumento CSPM, da scanner OSS o strumenti analoghi

La maggior parte di chi lavora nella sicurezza del cloud ha già interiorizzato questo concetto, ma non sempre lo esplicitiamo. Osservando alcuni strumenti di Cloud Detection and Response (CDR), si nota che generano avvisi su determinate configurazioni errate. È un approccio diverso dalla modalità predefinita degli strumenti CSPM, che creano risultati in report e dashboard. Questi ultimi sono importanti per la conformità e per l'igiene generale della sicurezza, ma poiché gli attaccanti compiono azioni sgradevoli come condividere immagini disco con altri account o creare accessi backdoor a ruoli IAM, un sottoinsieme di configurazioni errate va davvero trattato come se fossero indicatori di compromissione fino a prova contraria.

Internamente (e nella piattaforma DisruptOps) gestiamo tutto questo con una serie di rilevatori di minacce in tempo reale che attivano valutazioni sulla base di chiamate API identificate. Occorrono circa 15-30 secondi per identificare una configurazione errata e inviarla al team di sicurezza e al responsabile del progetto tramite Slack (o Teams), come illustrato sopra. Questi avvisi vengono trattati come un risultato di GuardDuty o qualsiasi altro indicatore di compromissione, ma l'uso del ChatOps per validare le attività ci aiuta anche a effettuare il triage molto rapidamente, senza dover eseguire ogni volta un'analisi approfondita.

In sintesi, la raccomandazione è: gestire le configurazioni errate critiche del cloud in tempo quasi reale e trattarle come indicatori di compromissione fino a prova contraria.

Nessun gatto è stato maltrattato durante la stesura di questo articolo.