Fino a poco tempo ci si vantava dell’uptime dei propri server, un’abitudine che è stata travolta dalla presa di coscienza che un server su cui si esegue il reboot per molto tempo sia un server esposto a rischi. Da lì in poi il Vulnerability Management ha assunto per le organizzazioni sempre maggiore importanza, con l’introduzione di strumenti in grado di individuare le vulnerabilità e gestirne il patching nel migliore dei modi.
Ma perché comunque il Vulnerability management non deve essere considerato un sistema di difesa sufficiente?
Nelle due immagini sottostanti potete osservare la medesima applicazione in due differenti condizioni: la prima mostra un’installazione rimasta “congelata” sette mesi (infatti è mancante di ben 14 aggiornamenti) su cui, nel periodo indicato, sono state individuate 20 vulnerabilità di livello High, mentre la seconda riguarda una versione installata da sette giorni e su cui tutte le vulnerabilità risolvibili sono state risolte.
E questo scenario riguarda solo uno dei diciotto microservizi dell’applicazione; si può quindi stimare che nel complesso, in sette mesi, si siano accumulate centinaia su centinaia di vulnerabilità.
La dimostrazione di quanto il Vulnerability Managent sia paragonabile ad una fatica di Sisifo lo si può vedere dalla schermata seguente.
La nuova versione dell’applicazione possiede ancora una vulnerabilità di livello High per un semplice motivo: la soluzione era disponibile da sei giorni quando la nuova release era stata rilasciata sette giorni prima.
Queste analisi sono state realizzate grazie alla soluzione PrismaCloud di Palo Alto Networks, leader di mercato per la gestione delle vulnerabilità in ambiente microservizi.
Considerato che in un mondo di microservizi il patching non esiste, da queste analisi possiamo trarre alcuni importanti insegnamenti dal punto di vista della Cybersecurity:
- è fondamentale tenere un alto tasso di aggiornamento per le applicazioni per ridurre al minimo il numero delle vulnerabilità presenti nel sistema;
- il Vulnerability Management da solo non basta e ma deve essere associato a sistemi di protezione del runtime, poiché è impossibile avere sistemi scevri di vulnerabilità.
Le organizzazioni dovrebbero dunque effettuare delle valutazioni dal punto di vista della propria Security nella scelta di applicazioni COTS (Commercial Of The Shelf).
Uno dei criteri scelta, o comunque uno degli di impegni contrattuali da inserire, dovrebbe essere quello legato alla gestione del versioning di sicurezza. Mentre un tempo la responsabilità della gestione delle vulnerabilità ricadeva sul cliente, adesso sono i fornitori dell’applicazione che si devono impegnare ad un regolare e costante rilascio di nuove versioni focalizzate sulla risoluzione delle vulnerabilità.
Kasten K10 di Veeam da questo punto di vista è un esempio virtuoso, dato che può arrivare al rilascio di una nuova versione ogni 15 giorni.
L’impatto a livello di processi non è indifferente, si passa a patch periodici delle VM ad upgrade periodici delle applicazioni. L’aspetto positivo è che così facendo i rilasci sono eseguiti per tutta la pila e con la certificazione del vendor, evitando le attività di analisi della backward compatibilty. Inoltre, essendo necessario adeguarsi ad un ritmo serrato di upgrade delle applicazioni, diventa essenziale operare in un contesto di vero DevOps, anche per le applicazioni COTS, con un processo continuo di rilascio dagli ambienti di test ed UAT verso la produzione.
Quando si parla poi della Software Factory in-house, il discorso diventa ancora più articolato.
Anche in questo caso si deve partire dal processo e dai ruoli. Il versioning di sicurezza deve diventare una parte fondamentale del processo di rilascio delle applicazioni, con la stessa dignità e priorità del rilascio di nuove funzionalità di Business.
Sulla Pipeline si dovranno prevedere, oltre ai Fork applicativi, i Fork di sicurezza per garantire un costante aggiornamento della versione corrente mentre già si lavora al rilascio della versione Next.
Inutile sottolineare come il paradigma dello Shift-Left debba diventare un imperativo nella Software Factory interna, cominciando dall’adozione di Sistemi di SAST (Static Application Security Testing) che consentono al developer un controllo real time delle vulnerabilità del codice prodotto, con l’obiettivo di rilasciare pacchetti che siano sicuri by design.
Importante in questa fase l’implementazione di una politica di verifica delle Supply Chain e delle Dipendenze Software per potersi mettere al riparo da attacchi mirati a questo anello della catena.
Considerata la cadenza dei rilasci effettuati in una realtà di DevOps, lo stesso approccio ai VA/PT deve essere cambiato per introdurre concetti di automazione ed integrazione nella Pipeline.
In questo può sicuramente aiutare l’adozione di Sistemi DAST (Dynamic Application Security Testing), che sono in grado di allineare la cadenza dei test sulle applicazioni a quelli del ciclo di rilascio della applicazioni stesse, operando preferibilmente sull’ambiente di UAT in modo da poter correggere le vulnerabilità prima che queste vengano messe in produzione.
Ovviamente i sistemi SAST e DAST necessitano di un compendio costituito dai sistemi puri di Vulnerability Management che devono applicare, tramite una forte integrazione con lo strumento di Pipeline Management, le policy aziendali di sicurezza sui Registry privati e sulle immagini a runtime.
Un ulteriore elemento è poi lo scan di sicurezza sui Git, un elemento che molti tendono a trascurare ma che diventa sempre più importante se pensiamo alla la rapida diffusione che gli strumenti di IaC (infrastrucutre as a Code) stanno avendo.
Concludiamo dicendo che è dunque fondamentale che nella Software Factory siano oggi introdotte specifiche politiche di gestione del versioning di sicurezza in modo che la Cybersecuity diventi parte integrante del processo di DevOps, in una modalità frictionless che non la faccia percepire come un fattore di freno all’agilità.
Una volta costruito un sistema efficiente e proattivo di gestione delle vulnerabilità, si deve poi affrontare la dura realtà che questo non sarà mai abbastanza efficiente da garantire la “pulizia” dei sistemi running nei diversi ambienti.
Il sistema di protezione dovrà partire dal presupposto che l’infrastruttura sia vulnerabile e possa essere compromessa.
Nota a latere: quanto detto in questo articolo vale anche per il mondo delle VM e dei server fisici, specie se si considera la numerosità dei sistemi con Sistemi Operativi fuori supporto, che da sempre sono il punto di attacco privilegiato da parte di hacker veri e Red Teams.
Il primo livello di protezione dovrebbe essere mirato contro gli attacchi che puntano alle vulnerabilità e da qui la necessità di Firewall di livello7, meglio se integrati nella pipeline di sviluppo con NGINX AppProtect.
L’altro aspetto importante è avere un sistema di Behaviour analisys in grado di individuare tutti i comportamenti sospetti delle applicazioni, bloccandoli od attivando il NOC (Network Operation Center) per l’analisi e la definizione delle contromisure.
È parimenti importante, infine, che tutto il sistema sia progettato secondo precise linee guida di sicurezza, la prima delle quali è sicuramente quella del least privilege per evitare che gli attaccanti possano utilizzare un oggetto od un’identità compromessi per prendere il controllo di porzioni più grosse del sistema.
