La veloce diffusione delle Tecnologie di Infrastructure as a Code, se da un lato crea una nuova sfida per chi deve implementare la sicurezza, dall’altro può essere un potente strumento per l’implementazione del concetto di Security by Design quando si parla di Infrastruttura.
Una delle grosse rivoluzioni in corso nel modo delle infrastrutture IT, molto legata allo sviluppo del Cloud, ma di cui si parla poco e che continua ad andare sottotraccia, è quella del IaC, l’Infrastructure AD Code. Banalizzando il concetto, l’intera infrastruttura è costruita partendo da un linguaggio di programmazione che ne definisce caratteristiche ed operatività. Questo approccio, che vede in Terraform e CloudFormation le due tecnologie di punta, consente di crearsi dei Git che contengono la descrizione completa della infrastruttura con grossi vantaggi in termini di versioning, documentazione, controllo.
Questo cambiamento nelle modalità di gestione della infrastruttura porta anche alla necessità di un ripensamento delle politiche di sicurezza simile a quello che vi è stato per lo sviluppo applicativo con l’introduzione degli strumenti di SAST.
Il fatto che esista un repository centrale, un git, che fa da single point of truth sposta il fulcro delle politiche di sicurezza verso questo nuovo soggetto, facilitando da un certo punto di vista il lavoro di chi è responsabile di sicurezza e compliancy che si trova a poter operare su uno strumento moderno da cui poter propagare le policy.
Dall’altro lato, si aprono però le strade per nuovi tipi di vulnerabilità e nuovi vettori d’attacco i cui effetti sono moltiplicati dalla possibilità di operare sulla fonte unica delle politiche di sicurezza. Un attacco ai Template dell’infrastruttura si propaga velocemente all’intero datacenter e può risultare molto più difficile da individuare, non avendo questa bisogno di nessun movimento laterale od operazione al di fuori dei normali pattern di operatività per installarsi su un nuovo sistema.
Così come la Sicurezza del codice è diventata una priorità per chi sviluppa applicazioni, così la sicurezza dei template IaC deve diventare una priorità per chi sviluppa ( perché si, adesso per le Architetture si sviluppa il codice, non implementano le configurazioni ) il codice dei Template.
I problemi per lo Scan di sicurezza dei Template non sono molto dissimili da quelli delle applicazioni, con la complessità ulteriore di esse stratificate su un numero di livelli ciascuno con le proprie peculiarità dal punto di vista della protezione e della Compliancy e, molto spesso, i propri Git dedicati.
Nella figura che segue vediamo per esempio la rappresentazione dal punto di vista del IaC di un’architettura di nuova generazione basata su Kubernetes: sul primo livello abbiamo i Template della infrastruttura, Terraform o CloudFormation od ARM che siano, uniti a quelli per le funzionalità Serverless. Sul secondo livello abbiamo gli Helm Chart che definiscono l’ambiente Run Time, e di conseguenza la sicurezza, della singola applicazione. A livello più alto i container sono poi il vero e proprio codice e che ad oggi sono già coperti con i classici strumenti di SAST e di VA.
(fonte: PaloAlto Network)
Come si può vedere, per i primi due livelli, si parla di “misconfiguration” e non di vulnerability, si tratta di errori umani che, se fatti nella prima parte della catena, si diffondono in tutta l’infrastruttura con un potente effetto leva.
Un approccio basato su strumenti di IaC introduce enormi benefici in termini di flessibilità e velocità d’uso, di automazione spinta e standardizzazione, ma bisogna anche tenere conto che questi sono tutti fattori che, dal punto di vista sicurezza, introducono una complessità intrinseca ed una maggiore difficoltà di controllo.
Una prima considerazione è che, quando si parla di chi fa Operation, risulta sicuramente molto più semplice ed efficace riutilizzare ed eventualmente customizzare artefatti disponibili nei repository pubblici piuttosto che riscrivere da zero la propria libreria.
La disponibilità di librerie di template all’interno dei repository pubblici a cui poter attingere per la costruzione dei propri modelli IaC fornisce a cui opera sull’infrastruttura di definire in pochissimo tempi ed a costi minimi anche le Architetture più complesse. Questo vantaggio in termini di flessibilità e velocità viene però ad un costo, dato che l’attività di manutenzione dal punto di vista di sicurezza di queste librerie è purtroppo minima.
Una recente survey di Unit42 (*) ha trovato che degli Helm Chart presi in considerazione, il 99.9% conteneva configurazioni insicure, che il 6% dei template IaC aveva misconfiguration critiche, il 62% provenienti da dipendenze e quindi più difficili da individuare, con una preponderante prevalenza di problemi legati ad Over-privileged containers. Un’altra analisi fatta utilizzando Chekov specificatamente nel repository Open Source di Terraform su 4.055 Template Terraform e 38.480 Terraform File, ha evidenziato che il 63% aveva una o più configurazioni insicure, di livello critico o comunque alto nel 49% dei casi.
A livello informativo possiamo anche elencare i principali punti di non conformità rilevati nei template, ovvero mancanza di limitazioni all’Accesso alla porta 22, mancanza di encrypting dei dati, utilizzo di service account di default, mancato enforcing sugli algoritmi di cifratura dei pacchetti in rete. Tutti problemi che possono lasciare porte aperte ad attacchi alla propria infrastruttura ed ai propri dati.
E’ facile a questo punto vedere come la compliancy di una infrastruttura alle principale normative, CIS, PCI-DSS; GDPR, HIPAA ed altri deve partire dai template che creano l’infrastruttura stessa, la certezza di avere template compliant semplifica di un ordine di magnitudine la gestione della compliancy dell’intera infrastruttura
Ci sono alcuni tools Opens Source, per esempio OPA, Open Policy Agent, oppure Checkov di Bridgecrew, che permettono di fare scan basati sulle Policy più comuni dei template IaC nondimeno, per una completa protezione, un tool Enterprise come PaloAlto Prisma Cloud è in grado di offrire funzionalità sicuramente più complete.
Quando si parla di riutilizzo dei template infrastrutturali, non si deve dimenticare poi che esiste il problema della Supply Chain, con tutta una serie di package importati via IaC, a volte in una catena di dipendenze molto lunga, che possono infettare l’infrastruttura e che potrebbero passare inosservati agli scan di sicurezza. Per questo motivo, nella scelta di uno scan per l’IaC, particolare attenzione deve essere posta alla sua capacità di risalire le dipendenze all’interno della Supply Chain per individuare tutte le misconfiguration e le vulnerability, non solo quelle presenti nel proprio git aziendale.
Quando si parla di sicurezza per il mondo dell’Infrastructure as a Code, si deve sempre tenere presente che esistono due precisi momenti che devono avere pari dignità: uno è quello dello Scan delle vulnerabilità e delle misconfiguration e l’altro è quello dell’enforcement dei guardrail.
Si deve tenere presente il fenomeno del Cloud Drift dove per diverse motivazioni, pressioni sui tempi di rilascio, incidenti che richiedono una fix immediata, procedure operative lasche od altro, le modifiche vengono apportate ai sistemi live senza toccare i Template IaC che restano così out of sync. Le stesse modifiche alle API dei Cloud Provider possono andare ad invalidare i Template facendo sì che il Git cessi di essere il “single point of truth” dell’infrastruttura.
Per questo motivo lo scan dei git non può essere considerato sufficiente per una protezione efficace di un processo GitOps ma si debbano integrare anche strumenti in grado da un lato di prevenire i drift, individuandoli e permettendo ai SecOps od agli Ops di aprire delle pull request per il riallineamento dei Template a quella che è la reale configurazione sicura propagandola eventualmente anche al resto della infrastruttura.
Un ulteriore punto da tenere in considerazione è poi quello della protezione totale della Pipeline di Continous Integration dato che questa diventa un cardine per la sicurezza della Infrastruttura essendo un potenziale Vettore di Attacco ad alta pericolosità. Un attacco riuscito alla CI Pipeline permette per esempio di “avvelenare” i template e di propagare, in forma non rilevata, le vulnerabilità a tutta l’infrastruttura lasciandola indifesa rispetto ad esfiltrazione dati ed a strumenti di Command and Control.
Quello che sempre più si rileva negli scan di sicurezza sui Git è la presenza di Hardcoded Credential, di session token e di access key, a volte inseriti appositamente, a volte dimenticati inconsciamente, che di fatto sono dei pericolosi entry point per tutta l’infrastruttura che riesco ad ottenere semplicemente violando una credenziale per un Git che spesso è pubblico.
Volendo riassumere, la necessità di coniugare velocità e sicurezza continuano ad essere la principale preoccupazione per i responsabili della Cybersecurity e la nuova frontiera dell’introduzione degli strumenti di IaC per la gestione del Cloud e delle nuove architetture Agile è una delle aree su cui deve essere spostata la focalizzazione con investimenti mirati all’acquisizione strumenti specifici Cloud Native. L’IaC è una sfida per le struttura di Cybersecurity ma, se ben utilizzato, può anche diventare il miglior strumento per l’enforcement dele Policy e l’implementazione di una filosofia di Security-by-design che dalle applicazioni si sposti alla infrastruttura.
Fonti
https://www.paloaltonetworks.com/cyberpedia/what-is-iac-security
https://www.paloaltonetworks.com/blog/prisma-cloud/announcing-multi-cloud-drift-detection/
(*) https://start.paloaltonetworks.com/unit-42-cloud-threat-report-2h-2021.html
