Perché non è ancora il momento del DevSecOps

Si parla sempre di più di DevSecOps per securizzare l’ambiente di sviluppo. Questo approccio, però, oggi sconta ancora lacune sia sul fronte tecnologico che di quello dei processi.
DevSecOps

Si parla sempre di più di DevSecOps per securizzare l’ambiente di sviluppo. Questo approccio, però, oggi sconta ancora lacune sia sul fronte tecnologico che di quello dei processi.

Articolo di Paolo Maggioni, Sales Specialist di Aditinet Consulting

Ai lettori di questo articolo chiedo di non fraintenderne il titolo; affrontare la sicurezza su Kubernetes non è mai stato urgente come in questo momento storico.

È proprio per questo che si devono impostare delle priorità per realizzare un progetto vincente di messa in sicurezza e, in questo senso, l’implementazione di un processo di puro DevSecOps deve necessariamente passare in secondo piano rispetto agli interventi di securizzazione dell’ambiente Kubernetes.

PERCHE’ BISOGNA PRIMA PENSARE ALLA SICUREZZA DELL’AMBIENTE K8S

L’urgenza di mettere in sicurezza gli ambienti Kubernetes nasce da una sempre maggiore diffusione di applicazioni Mission Critical che sono portate su questo ambiente a fronte di un approccio alla Security che sinora si è sempre affidato ad una sorta di “isolamento fisico e culturale”.

Nessuno infatti fino ad oggi si è occupato seriamente di sicurezza su Kubernetes per il fatto che ci si affidava ad installazioni Sandbagged; si è sempre ritenuto che ogni incidente si limitasse alle applicazioni che vi giravano, le quali per lo più erano frutto di sperimentazioni senza valore per il business e, per questo, sacrificabili.

Anche dal punto di vista degli attaccanti Kubernetes è stato finora poco appetibile, un ambiente su cui c’era poca conoscenza, isolato dalla rete aziendale (spesso in cloud) ed usato per applicazioni giocattolo; non valeva la pena investire tempo per capire la superficie di attacco ed i possibili exploit.

Ma oggi la situazione è cambiata.

Parlare di Kubernetes oggi vuol dire parlare di applicazioni Mission Critical; si tratta di un ambiente dinamico integrato nella rete aziendale, che deve essere protetto sia in funzione delle applicazioni che vi girano sia per evitare che diventi una testa di ponte per un attacco al datacenter.

Cominciamo da una considerazione: un container non è una VM e quindi gli ambienti containerizzati sono per definizione meno isolati e più esposti. Un namespace si può isolare dal punto di vista applicativo, ma se non viene “hardenizzato”, porta ben pochi isolamenti dal punto di vista della Security.

Sono quindi tantissimi gli accorgimenti che vanno portati ad un ambiente Kubernetes per renderlo sicuro.

Per prima cosa bisogna limitare al massimo la presenza di container privileged, gestire correttamente ServiceAccount e Role, proteggere i secret, garantire un vero isolamento dei namespace, proteggere il sistema da containers compromessi ed individuare ogni lateral movement; soprattutto è necessario proteggere traffico Est-Ovest e traffico Nord-Sud, che hanno due filosofie di funzionamento completamente opposte.

Teniamo conto, poi, del fatto che possiamo avere decine di migliaia di container in un cluster che potrebbero portare a centinaia di migliaia di connessioni da proteggere in una contesto dove i deploy sono continui e l’ambiente muta costantemente.

PERCHE’ PASSARE SUBITO AL DEVSECOPS NON É LA SCELTA MIGLIORE

Il DevSecOps sembrerebbe essere a questo punto la naturale risposta al problema, la soluzione disponibile che necessita solo di qualche cambio organizzativo e della scelta dei giusti tool: “Faccio in modo che i team DevOps acquisiscano anche competenze di Security e faccio in modo che nel ciclo di vita dell’applicazione sia inclusa anche tutta la gestione degli aspetti di sicurezza e compliance dell’applicazione stessa, possibilmente con un approccio dichiarativo Kubernetes-native”.

Approccio perfetto sulla carta, ma che sconta ad oggi dei problemi di processo e di strumenti.

Il primo scoglio è sicuramente quello organizzativo, visto che il DevSecOps implica un cambio di processo e di approccio.

Per gestire bene la sicurezza all’interno dei Team di sviluppo bisogna prima capire quanti SecOps sono in azienda e quanti se ne possono assegnare a tempo pieno al DevSecOps, calcolare poi il loro rapporto rispetto ai Developers (è forse di 1 a 100 al momento e quindi il compito sarebbe immane).

Un’alternativa potrebbe essere quella di creare skill all’interno dei gruppi con programmi per i Developer ma, diciamocelo pure, i developer non amano la Security, che considerano un freno al rilascio veloce di software che funzioni. Un cambiamento culturale che richiederà anni.

E comunque resta un problema di fondo: chi o cosa si occupa di verificare la conformità rispetto alle normative aziendali e di settore delle policy implementate da ogni singolo team di DevSecOps aprendo quindi il fronte della maturità dei tool?

Se è pur vero che gli strumenti di gestione della sicurezza nativi di Kuberntes adesso non mancano, si tratta delle Network Policy, complete, potenti e gestibili in un contesto di integrazione con la pipeline di sviluppo, perfette per il DevSecOps, è altrettanto oggettivo che siano onerose da gestire.

Infatti, per prima cosa, mancano in maniera diffuse le skill necessarie per creare e manutenere manifest personalizzati per ciascuna applicazione e, comunque, il problema di fondo è che la creazione dei manifest di sicurezza è ancora un lavoro manuale e labour intensive, decisamente troppo pesante per un’economia di progetto.

In secondo luogo, inoltre, mancano gli strumenti di gestione delle policy capaci di individuare ridondanze, scoperture o pericolosi blocchi dei servizi.

Ricordiamoci che questi strumenti ragionano in un’ottica di Zero Trust e quindi ogni errore causato da un flusso non censito all’origine potrebbe portare ad un blocco dell’applicazione.

Ad oggi un approccio con le Kubernetes Network Policy può aver senso se le regole sono integrate nell’applicazione e gestite dall’ISV che sviluppa e manutiene l’applicazione stessa ed include le regole nel proprio Helm. Pensare però di gestirle in casa porterebbe ad un carico di lavoro per gli XXXOps (scrivo XXX perché sarebbe poi da capire chi fra Dev, Sec ed Ops le prenderebbe in carico) assolutamente non gestibile senza tool che  permettano una piena automazione della creazione e della manutezione delle regole.

Guardando il mercato, ci sono strumenti veramente validi di implementazione delle Network Policy, cito Calico e Cilium fra i migliori, ma forniscono tanta potenza senza un effettivo controllo e sono quindi un potenziale fattore di rischio per gli SLA.

QUINDI COME DOVREBBERO PROCEDERE LE AZIENDE PER MIGLIORARE LA SICUREZZA DEGLI AMBIENTI DI SVILUPPO?

L’approccio in questo momento premiante è quello di lasciare i SecOps all’esterno del gruppo di lavoro, dotandoli però di strumenti Kubernetes Native in grado di iniettare la Security all’interno del cluster o delle applicazioni, limitando al minino la frizione con i DevOps.

Il primo strumento che può aiutare ad aumentare i livelli di Security del traffico Nord-Sud e Est-Ovest è l’adozione di un WAF che crei una prima protezione del cluster e/o dell’applicazione.

Il WAF potrebbe essere statico sugli ingress oppure agganciato alle singole applicazioni da proteggere o con interventi dei SecOps sulla consolle dello strumento o tramite pochi manifest generati e manutenuti dai DevOps inseriti nei chart di rilascio dell’applicazione.

Questi due approcci si adattano alle due soluzioni di punta Twistlock/PrismaCloud e NGINX/App Protect.

Il metodo migliore al momento è quello di agire all’interno del cluster Kubernetes con un autoapprendimento basato sulla analisi del behaviour dell’applicazione e dei relativi scostamenti e con l’utilizzo di algoritmi automatici AI based per individuare gli attacchi e le esfiltrazioni.

In questo modo si limita al minimo l’overhead di gestione delle regole e si può, anzi, si deve integrare con la pipeline di sviluppo perché l’apprendimento del comportamento dell’applicazione, anzi di quella specifica build dell’applicazione, avvenga già durante le fasi di test ed UAT.

Un approccio di lavoro basato sul comportamento dell’applicazione ha inoltre il vantaggio di individuare in anticipo i segnali legati ad un attacco effettuato sfruttando vulnerability dei container, perché non si limita al traffico di rete ma è in grado di individuare situazioni sospette legate ai processi, agli accessi ai file system e alle porte che vengono aperte.

Parlando poi di processi, sarebbe buona norma schedulare con cadenza periodica un Penetration Test, buona pratica per validare le policy in place.

Vulnerability Management”: ne parliamo alla fine, oramai sono quasi una commodity. In questo caso forse si può parlare di DevSecOps con cognizione di causa.

Ci sono talmente tante soluzioni disponibili, anche open source, che non è possibile pensare di non averne adottata almeno una.

L’importante è applicare il controllo delle vulnerabilità il prima possibile all’interno della pipeline; il concetto di shift left deve essere mirato al developer, poiché è lui che crea i container ed ha il controllo di questa fase e, quindi, è l’unico che allo stato dell’arte può fare remediation.

D’altronde i container non si “patchano”; se si trovano vulnerability in UAT non si possono correggere lì, ma devo rimandare tutto al Dev che deve ricreare il pacchetto.

Meglio quindi che il processo imponga criteri automatici stringenti a quanto esce dalla prima fase e che le applicazioni arrivino al test già perfette dal punto di vista Security.

E consideriamo poi il problema delle applicazioni che non sono sviluppate in-house: in una architettura legacy si possono applicare le patch di sicurezza al Sistema Operativo o al middleware; in un sistema a Container, invece, si è dipendenti dalla volontà di chi ha generato il pacchetto nel rilasciarne una versione con le patch corrette.

Questa è un’area su cui la community di CyerSecurity dovrà lavorare: la possibilità di intervenire con patching di Security sulle immagini nei registry senza dover richiedere la ricreazione dell’immagine. Una problematica per cui il mercato non ha ancora dato una risposta credibile.

Per concludere vorrei specificare che questo articolo è da contestualizzare rispetto a questo momento storico specifico.

L’esigenza di mettere in sicurezza i cluster Kubernetes è talmente pressante che non è possibile affrontarla con i tempi lunghi richiesti dall’implementazione di un processo DevSecOps efficace ed efficiente, considerata soprattutto l’immaturità dei tool di Policy Management per Kubernetes.

Speriamo quindi fra sei mesi di poter arrivare con un articolo dal titolo: “Regole per un approccio di successo al DevSecOps”. Se volete ricevere maggiori informazioni sulle tecnologie e processi per una corretta securizzazione degli ambienti di sviluppo aziendali, potete mandare una richiesta all’indirizzo sales@aditinet.it.

Share on facebook
Share on twitter
Share on linkedin
Share on whatsapp
Share on telegram
Share on email
Share on print

Articoli correlati

Non sei ancora iscritto alla nostra newsletter?

Torna su