È noto che il panorama delle grandi aziende legate al mondo ed ai mercati dell’Information Technologies sia sempre in grande fermento e, soprattutto negli ultimi anni, si registra una crescente esigenza in termini di servizi e di risorse: per tale ragione, molte aziende stanno valutando un cambiamento radicale, spostando la loro attenzione su soluzioni Cloud oriented che richiedono un nuovo approccio alla Cloud Enterprise security.
Indice degli argomenti
I punti chiave di una soluzione cloud
Microsoft definisce il cloud come: “un sistema per la distribuzione di servizi di calcolo, come server, risorse di archiviazione, database, rete, software e intelligence, tramite Internet (“il cloud”), per offrire innovazione rapida, risorse flessibili ed economie di scala. Paghi solo per i servizi Cloud che usi e risparmi sui costi operativi, esegui l’infrastruttura in modo più efficiente e ridimensioni le risorse in base all’evoluzione delle esigenze aziendali”.
Partendo da questa definizione, è facile intuire il perché sempre più aziende siano attratte da questa nuova tecnologia. In particolare, i punti chiave di una soluzione cloud sono declinabili in:
- costo: elimina i costi relativi all’acquisto di hardware e software ma anche quelli relativi alla loro gestione (manutenzione hardware, gestione dei data center, personale ecc.);
- scalabilità: probabilmente uno dei vantaggi più grandi per le esigenze delle aziende. Infatti, avere risorse scalabili significa disporre di maggiore o minore capacità di potenza di calcolo, risorse di archiviazione, ecc. solo quando necessario e di conseguenza pagare solo per ciò che viene realmente utilizzato;
- prestazioni: tipicamente un servizio cloud viene erogato utilizzando un’architettura server distribuita, del tutto trasparente per l’utente, e caratterizzata da server dotati di Hardware all’avanguardia e costantemente aggiornati.
Cloud Enterprise security: un nuovo approccio alla sicurezza
Prima dell’avvento del cloud, le aziende erano in qualche modo costrette ad ospitare diverse apparecchiature hardware all’interno dei propri Centri di Elaborazione Dati (CED). Quello che è cambiato in questi anni è che, passo dopo passo, le aziende si sono sempre di più spostate verso un approccio ibrido, prevedendo che alcune risorse venissero gestite On-Premise mentre altre fossero dislocate nel cloud.
Molti sono i cambiamenti e gli adattamenti che gli utenti consumer, ma specialmente le aziende, si ritrovano a intraprendere soprattutto per il notevole livello di astrazione messo in campo da questa nuova tecnologia.
Uno di questi cambiamenti è proprio l’approccio alla sicurezza che prevede l’uso di nuove tecnologie e l’adattamento, ove possibile, dei consueti concetti di security con strumenti che in parte e spesso un buon cloud provider mette a disposizione.
Molte aziende giovani e innovative decidono di strutturarsi e puntare con forza sin dall’inizio su soluzioni cloud oriented. Per fare un esempio concreto, nella nostra attuale esperienza lavorativa, abbiamo potuto notare come il cuore pulsante di tutta l’infrastruttura sia ospitato in cloud e gestito internamente da un team di persone altamente qualificate: lo SRE Team (Site Reliability Engineer Team).
Le uniche risorse hardware ospitate On-Premise sono quelle relative alla network security, quindi firewall, switch eccetera. Un ulteriore improvement tecnologico su cui si è deciso fortemente di puntare è l’utilizzo di tecnologie moderne ed orientate al cloud quali:
- Kubernetes: strumento di orchestrazione e gestione dei container, sviluppato da Google. Consente di eliminare molti dei processi manuali coinvolti nel deployment e nella scalabilità di applicazioni containerizzate. Consente di gestire con semplicità ed efficienza cluster di host su cui vengono eseguiti container Linux;
- Docker: tecnologia di containerizzazione che consente la creazione e l’utilizzo di container Linux.
Analizzando lo stack tecnologico implementato, abbiamo dovuto ridisegnare e adeguare i nostri standard di sicurezza, non tanto per quanto riguarda la componente applicativa, messa in sicurezza con periodici cicli di penetration test, quanto per quella infrastrutturale.
In particolare, per quest’ultima abbiamo deciso di utilizzare diversi approcci:
- penetration test e attività di Red Teaming sulla nostra infrastruttura ospitata in cloud:
- enumerazione dei permessi per un account, simulando un utente esterno compromesso;
- Privilege Escalation;
- tentativi di compromissione dei servizi di monitoring and logging messi a disposizione per la nostra infrastruttura dal Cloud Serice Provider;
- tentativi di creazione di accessi mediante “backdoor account”;
- simulazione furto di credenziali a danno di un utente interno alla nostra organizzazione, mediante tecniche di social engineering, phishing ecc.;
- Web e Mobile Penetration Test sulle nostre applicazioni sviluppate In-house;
- Attività di Blue Team:
- rilevazione di path di attacco utilizzando strumenti quali firewall, IDS/IPS ecc.;
- setup di alert specifici sul nostro sistema di monitoraggio interno;
- sviluppo di custom signatures per attacchi non noti e correttamente identificati;
- setup e gestione dei Web Application Firewall;
- Kubernetes e Container Security:
- penetration test, partendo dalla metodologia classica per evolvere verso attacchi specifici ed emergenti relativi a questo ambito;
- messa in capo di soluzioni tecnologiche, innovative ed avanzate per la protezione delle immagini docker e dei container.
Per quanto riguarda quest’ultimo punto, è necessario sottolineare come sia stato necessario integrare queste soluzioni all’interno della pipeline di Continuous Integration/Continuous Deployment (CI/CD) affinché i problemi di sicurezza legati soprattutto alle immagini docker, potessero essere evidenziati e corretti prima del deploy in produzione.
Cloud Enterprise security: i criteri minimi
In particolare, abbiamo definito dei criteri minimi di sicurezza che ciascuna immagine docker deve possedere per approdare in produzione. Una volta distribuita, è buona prassi effettuare un vulnerability assessment periodico alla ricerca di eventuali nuove vulnerabilità da correggere.
Per quanto riguarda le regole di compliance, la conditio sine qua non che permette ad una immagine di essere deployata in ambiente di produzione, consiste nell’impedire che ciascun container possa essere eseguito con un utente avente privilegi elevati (root user).
Tipicamente anche questo genere di controllo è integrato lungo la pipeline CI/CD, per cui tutte le immagini utilizzate non dovrebbero approdare in produzione portando con sé questo genere di misconfiguration. Tuttavia, una violazione di tale regola di compliance, in ambiente di produzione, fa scattare un allarme che permane fino alla corretta sistemazione della suddetta problematica.
Altri espedienti tecnologici innovativi sono stati implementati sui nostri container e questi sono:
- Cloud Native Application Firewall (CNAF)
- Runtime Rules
Per quanto riguarda il CNAF, questo è assimilabile a un Web Application Firewall, appositamente disegnato per la protezione dei container. In particolare, un WAF difende un’applicazione web ispezionando il traffico di livello 7 del protocollo TCP in transito verso e dall’applicazione e andando a bloccare pattern noti di attacchi (es. XSS, SQL injection ecc.).
Il CNAF opera in cooperazione con il Defender, uno di componenti principali della soluzione che adoperiamo per la container security. Il Defender si comporta come un normale HTTP Proxy trasparente e valuta le richieste in transito verso la web application, sulla base delle regole precedentemente configurate, decidendo quindi se lasciar passare o meno la richiesta.
In altre parole, viene eseguito una sorta di Man-in-the-Middle sul traffico, decrittandolo nel caso di richieste crittate utilizzando TLS, e analizzandone il contenuto per verificare la presenza o meno di payload malevoli.
In definitiva, il CNAF in accoppiata al WAF applicativo Layer 7, tipicamente presente su Load Balancer applicativi, rappresenta un secondo strato di protezione da applicare al container su cui risiede il codice della web application.
Cloud Enterprise security: l’approccio Purple Team
L’altro espediente molto importante nella protezione e nel rilevamento di anomalie, a seguito di potenziali compromissioni, è messo in atto dal componente preposto ai controlli di Runtime e gestito dal Defender.
Ci si aspetta che, in un modo o nell’altro, un attaccante dotato di elevate competenze prima o poi possa riuscire a superare le protezioni della Web Application e arrivare sui server di backend.
Nel contesto della Container Security (CS), questo significa sostanzialmente il bypass delle misure di protezione proattive descritte in precedenza e delle misure di sicurezza implementate sulla web application (es. security framework, sanitizzazione input utente ecc.).
È sempre una buona idea vestire i panni dell’avversario più abile e capire che una volta avvenuta una simile compromissione quello di cui si ha bisogno è allarmistica, quanto più puntuale possibile.
Nel corso di questo articolo abbiamo accennato a strumenti come IDS, WAF e Defender, misure network e applicative necessarie per identificare e mitigare la maggior parte degli attacchi. Una volta ottenuto l’accesso sul container però un attaccante avrà a disposizione un nuovo punto da cui muoversi e potrà effettuare una serie di attività tra cui, ad esempio:
- cercare di elevare i propri privilegi se ridotti;
- attaccare altri sistemi raggiungibili (Pivoting);
- cercare informazioni utili all’interno del sistema (secret, configurazioni, script ecc.);
- modificare file di configurazione, account ed installare backdoor per accessi futuri;
- cercare di esfiltrare dati se ha avuto la fortuna di giungere su un sistema che ha diretta visibilità su sistemi di backend o se è esso stesso un sistema di backend.
In questo caso il motore di Runtime gestito dal Defender ci aiuta a identificare le più comuni backdoor e alterazioni che un attaccante tenta di eseguire all’interno del container. Si tratta infatti di quello che potremmo definire come HIDS ovvero Host Intrusion Detection System che, identificati una serie di comportamenti e di processi in esecuzione, traccia le anomalie sul sistema operativo monitorato, inviando degli allarmi non appena vengono rilevati dei processi o dei comportamenti sospetti.
Prendendo ispirazione dai TTP del MITRE Att&ck abbiamo adottato un approccio più spinto, che ha previsto la scrittura di regole ad-hoc, per identificare alcuni pattern di attacco specifici.
Conclusioni
Siamo consapevoli di poter sempre migliorare la nostra security posture aziendale, alzando ulteriormente l’asticella. Ancora una volta però crediamo, e continueremo a credere, che un approccio di tipo Purple Team (Red e Blue team), in cui la cooperazione costituisce un elemento cruciale, possa essere l’arma più potente per costruire aziende più sicure.
