Gli attacchi di alto profilo alla supply chain software, come quelli contro Solar Winds e Kaseya VSA, hanno fatto emergere la disparità tra la percezione di sicurezza delle aziende all'interno della propria infrastruttura cloud, e la realtà delle minacce nelle proprie supply chain, che possono avere un impatto catastrofico sul business.

Informazioni utili per dissipare questa disparità sono contenute nel Cloud Threat Report 2H 2021 di Unit 42, la costola di cyber security di Palo Alto Networks. L'analisi si basa sui dati provenienti da una varietà di fonti pubbliche globali, da cui emergono fondamentalmente due informazioni allarmanti.

La prima è che il 63% dei modelli di codice di terze parti utilizzati nella creazione dell'infrastruttura cloud contiene configurazioni non sicure. La seconda è che il 96% delle applicazioni container di terze parti distribuite nelle infrastrutture cloud contiene vulnerabilità note.

Il Red Teaming non perdona

Queste conclusioni sono ulteriormente confermate da un Red Teaming contro l'infrastruttura di un importante fornitore SaaS, cliente di Palo Alto Networks. In tre giorni un ricercatore di Unit 42 ha scoperto falle critiche nello sviluppo software che rendevano il cliente vulnerabile a un attacco simile a quelli subiti da Solar Winds e Kaseya VSA.

Il cliente in questione vantava quella che viene comunemente definita una posizione di cloud security matura. Tuttavia, il suo ambiente di sviluppo conteneva diversi errori critici di configurazione e vulnerabilità che hanno permesso a Unit 42 di assumere il controllo della sua infrastruttura cloud in pochi giorni.

Attacchi alla supply chain

Che cosa ha a che fare il caso appena citato con gli attacchi alla supply chain? La risposta è piuttosto semplice: nella maggior parte degli attacchi alla supply chain, l'attaccante compromette la rete di un fornitore e inserisce codice dannoso nel software utilizzato dai suoi clienti. L'infrastruttura cloud può cadere vittima di un approccio simile, se il codice di terze parti, che non è stato controllato, introduce delle falle di sicurezza.

È per questo motivo che le aziende hanno il dovere di verificare sempre le origini del codice di terze parti che adottano. La questione rientra nell'annoso problema della sicurezza DevOps, o DevSecOps che dir si voglia, ed è in parte all'origine delle minacce alle supply chain.

Le applicazioni native del cloud hanno una lunga catena di dipendenze. Tali dipendenze hanno a loro volta delle dipendenze proprie. Per abbassare la soglia di rischio è imperativo che i team DevOps e di security verifichino ogni carico di lavoro cloud per valutare il rischio in ogni fase della catena di dipendenze.

Le falle della supply chain nel cloud sono difficili da rilevare a causa dell'enorme numero di elementi costitutivi in gioco, anche in un'applicazione cloud-native di base. L'unico modo per limitare i problemi è spostare la sicurezza il più vicino possibile allo sviluppo. Questo comporta un cambiamento epocale, dato che storicamente i team di sicurezza e di sviluppo operano in maniera indipendente. Oltre tutto, i team di sviluppo tendono a muoversi rapidamente e ad abbracciare con entusiasmo le novità, mentre la security si basa su un approccio opposto.

Lo sforzo da fare non è cambiare radicalmente i comportamenti degli sviluppatori, ma dotare questi ultimi di processi e strumenti che introducano una sicurezza nativa nei loro metodi di sviluppo esistenti. E questo spetta ai team di sicurezza.

Cloud native

Atra questione è quella della migrazione cloud. Nella prima ondata migratoria c'è stato un passaggio lift and shift. Le aziende hanno semplicemente preso le applicazioni esistenti e le hanno trapiantate in cloud così com'erano. Il problema è che non erano cloud native e hanno esposto le infrastrutture a un elevato rischio informatico.

Per sfruttare tutti i vantaggi del cloud, l'applicazione stessa deve essere cloud native, quindi deve disporre di funzionalità quali IaC (Infrastructure-as-Code), container, Kubernetes e servizi basati su PaaS come Google Cloud SQL e Azure SQL.

Tali funzionalità vanno poi gestite. I codici di terze parti vengono regolarmente importati tramite modelli IaC che non vengono controllati, lasciando che le minacce informatiche passino inosservate. Sono proprio i modelli IaC che Unit 42 ha analizzato, scoprendo che il 63% dei 42.000 ispezionati conteneva almeno una configurazione critica o altamente insicura.

Il codice sorgente è quindi il primo elemento da proteggere, poi nell'ordine devono essere messi in sicurezza i materiali, la pipeline di compilazione, gli artifact e, infine, i deployment. In assenza di uno dei passaggi a monte, il deployment infetto può causare il ben noto effetto domino.