Quando si parla di container di applicazioni, come Docker, Rkt e Mesos Containerizer, alla maggior parte degli sviluppatori balzano in mente due cose: hanno rivoluzionato il modo di lavorare e dureranno a lungo. In effetti, la containerizzazione dell’IT semplifica il processo di rilascio di un software e fa risparmiare tempo nel mirroring delle piattaforme di produzione, per non parlare del tempo risparmiato nel debug effettivo dei problemi di configurazione. Inoltre, le configurazioni sono portabili e viaggiano assieme all’applicazione se il codice cambia ambiente.
Nulla da dire dunque: dal punto della velocità di sviluppo e commercializzazione del software, gli app container sono stati davvero rivoluzionari e hanno migliorato l’efficienza operativa. Dal punto di vista della sicurezza informatica, invece, la tendenza verso uno sviluppo software in tempi sempre più stretti rappresenta un problema. La sfida principale è tenere traccia delle vulnerabilità degli app container e mitigarle, cosa che può risultare estremamente complessa, soprattutto perché container diversi possono utilizzare versioni diverse del software.
Facciamo l’esempio di un ambiente che esegue due diverse applicazioni containerizzate, con entrambi i container che forniscono servizi di un’applicazione più ampia. Anche se scritti nella stessa lingua, tipo Python, potrebbero utilizzare una versione diversa del runtime; una potrebbe essere ad esempio Python 2.x e l’altra Python 3.x. Allo stesso modo, le librerie di supporto potrebbero essere diverse o, peggio ancora, potrebbero esserci versioni differenti della stessa libreria. Ma non è finita: potrebbero anche esserci middleware diversi, versioni diverse dello stesso middleware o configurazioni diverse per l’esecuzione dell’applicazione.
In realtà anche una situazione complessa di questo tipo potrebbe essere gestibile, ma solo fino a quando non iniziano a comparire le vulnerabilità di componenti, librerie e middleware. E prima o poi succede. Ecco perché, per prevenire i problemi, gli sviluppatori e i team di sicurezza devono tenere traccia di cosa è installato e dove, quale versione di ogni componente è in esecuzione su ciascun container, come vengono utilizzati i container e altro ancora. Si provi a immaginare un’azienda che di app container ne possiede centinaia o addirittura migliaia: tutto diventa molto complicato molto rapidamente.
Prevedere la scansione delle vulnerabilità dei container
L’utilizzo di vulnerability scanner tradizionali per affrontare le sfide poste dalla sicurezza dei microservizi presenta delle criticità. A parte l’aspetto della transitorietà, come per le virtual machine, il problema è che non c’è molto che un vulnerability scanning tool possa rivelare senza trovarsi all’interno del contenitore stesso.
Ecco perché è emersa una nuova categoria di tool di sicurezza per la scansione delle vulnerabilità degli app container. Si tratta di strumenti che danno visibilità agli elementi in esecuzione e forniscono informazioni sul software che potrebbe, all’interno del container, presentare delle vulnerabilità.
Sul mercato ci sono tanti prodotti commerciali di questo tipo, ma c’è anche una buona disponibilità di strumenti open source per il vulnerability scanning dei container. Per esempio Anchore Engine, il progetto Clair di CoreOS e Dagda, che identifica le configurazioni di container vulnerabili e, a seconda della configurazione, potrebbe anche cercare malware.
Vantaggi dell’open source
Come la maggior parte dei professionisti della sicurezza sa, gli strumenti di sicurezza open source possono offrire molti vantaggi anche in situazioni in cui che alla fine si passerà a uno strumento commerciale.
Il primo vantaggio dell’open source è che consente ai team di sicurezza di fare un rodaggio e ottenere elementi da utilizzare nella presentazione di un caso aziendale o nelle discussioni sul budget, dimostrando i benefici di un’attività di vulnerability scanning. Anche se in conclusione si deciderà di passare a un’alternativa commerciale, questo è utile. È interessante il sondaggio Security on the Shelf di Osterman Research in cui si rileva che il 28% degli strumenti di sicurezza finisce per essere shelfware, cioè un prodotto acquistato perché percepito come necessario ma che in realtà resta inutilizzato. In alcune organizzazioni la percentuale arriva fino al 60%. Dimostrare che l’azienda trarrà valore dallo strumento prima di effettuare un acquisto è importante.
Il secondo vantaggio è che disporre di solide opzioni open source comporta per i team la possibilità di agire senza dover attendere. La definizione del budget di cybersecurity può richiedere un anno intero, in alcuni casi di più, prima di ottenere le risorse necessarie a mettere in campo le misura opportune. A condizione, ovviamente, che le organizzazioni abbiano le competenze tecniche interne necessarie. Ciò può essere utile per chiudere rapidamente un audit, per proteggere un’area ad alto rischio o per qualsiasi altra situazione a breve termine in cui è fondamentale mettere in atto interventi rapidi.
Posto che un’attività di vulnerability scanning dei container è preziosa, e dato che ci sono più opzioni open source per realizzarla a un costo minimo, cosa si ha da perdere nel provarci?
