Quando si tratta l’argomento vulnerabilità non bisogna tralasciare il contesto in cui la vulnerabilità viene inserita. Il contesto di riferimento è la funzione del rischio. Il rischio lo intendo come funzione dipendente dal prodotto della minaccia per la vulnerabilità per l’impatto. La vulnerabilità ovviamente viene associata a un bene, inteso in questo caso come un asset informatico (hardware o software). Quindi il rischio è dato dalla probabilità che una minaccia sfrutti una vulnerabilità, presente su un asset, e provochi quindi un impatto.
Primo passo per gestire le vulnerabilità è raccogliere informazioni sugli asset. La gestione delle vulnerabilità è una tematica che affligge tutte le aziende, soprattutto le aziende complesse e di grandi dimensioni che nel corso degli anni hanno stratificato le proprie infrastrutture IT. Molte realtà si sono strutturate con propri datacenter per poi passare a sistemi ibridi, con la convivenza di datacenter interni e cloud; oppure si sono affidate a soluzioni completamente in cloud. Queste stratificazioni hanno aumentato la complessità delle infrastrutture stesse su cui poggiano i servizi aziendali.
Spesso le architetture non vengono aggiornate e si rischia di avere fotografato un’architettura in un tempo T0 che nel corso degli anni ha subito modifiche. Nelle aziende multi-servizi, dove, a volte, per ogni business unit esiste un referente IT, la gestione degli asset può essere ancor più critica se manca un coordinamento centrale fra tutti i referenti. Per non parlare dell’espansione del cloud, in cui gli asset sono gestiti da fornitori esterni, dell’avvento della tecnologia workload e della diffusione degli IoT. La tecnologia è in continua evoluzione ed è difficile stare al passo. Questo è determinato anche da un approccio a silos. Un problema annoso, che se ne dica, non è mai stato pienamente risorto. Per usare una metafora pubblicitaria: ogni mattina un manager si alza e sa che dovrà correre per raggiungere i propri obiettivi di business; ogni mattina un CISO si alza e sa che dovrà rincorrere un manager per mettere al sicuro il business.
La creazione di un gestionale centralizzato che raccolga e normalizzi le informazioni su tutti gli asset è una soluzione che potrebbe agevolare la gestione delle vulnerabilità ma non è da considerarsi sufficiente.
La piattaforma dovrebbe essere mantenuta e aggiornata e soprattutto dovrebbe essere arricchita da informazioni che permettano di contestualizzare l’asset. L’informazione principe è relativa al servizio a cui afferisce quell’asset. Solo con la contestualizzazione di quale servizio poggia su quell’asset, si può veramente comprendere quale ruolo abbia e quale criticità possa rappresentare una sua esposizione.
Ci saranno asset che supportano processi di business e asset che supportano processi interni, oppure entrambi i processi.
Il mantra è simile a quello della Polizia: segui i soldi. Identificare i servizi che generano i ricavi e la catena tecnologica che li supporta è un primo passo per garantire che i servizi a maggiore valore aggiunto possano essere protetti. A seconda del servizio supportato è necessario stabilire quale sia la rilevanza dell’asset stesso. Quindi è necessario effettuare una pesatura. La pesatura è dettata dalla tipologia di informazioni che tratta e dalla rilevanza che ha nel processo di creazione del valore. Questo è fondamentale per determinare l’impatto, nel caso in cui la vulnerabilità venga sfruttata.
Una volta raccolte le informazioni sugli asset e sui servizi a cui afferiscono, è necessario verificare che questi asset non siano affetti da vulnerabilità, perlomeno conosciute. E qui che entrano in gioco informazioni esterne all’azienda. Esistono database pubblici e a pagamento che mettono a disposizione informazioni sulle nuove vulnerabilità. L’acronimo utilizzato per identificare nuove vulnerabilità è CVE (Common Vulnerabilities and Exposures). Sono queste informazioni che devono essere correlate con le informazioni degli asset presenti in azienda.
Le vulnerabilità solitamente vengono pubblicate con un livello di gravità, calcolato considerando più parametri:
possibilità di accesso, di sfruttamento, complessità nello sfruttamento, l’impatto che può provocare in caso di sfruttamento e così via. La presenza di una vulnerabilità su un asset fa scattare tutta una serie di considerazioni di cui abbiamo accennato sopra e che considerano sia la rilevanza dell’asset contestualizzata sia la criticità della vulnerabilità. Oltre a ciò, sarebbe opportuno considerare anche chi possa essere in grado di sfruttare questa vulnerabilità. Qui si entra nella sfera della minaccia. L’esistenza o meno del cosiddetto exploit, l’accessibilità a questo exploit, il prezzo stesso dell’exploit sono ulteriori fattori da considerare nell’attribuzione del livello di criticità. Inoltre, considerazioni devono essere fatte anche su chi eventualmente abbia capacità di sfruttare quell’exploit.
Queste considerazioni servono a comprendere le tempistiche necessarie per il processo di patching. Il patching non è un processo immediato perché richiede un’analisi per comprendere quali possano essere le conseguenze dell’installazione della patch sul sistema. Inoltre, soprattutto in realtà complesse, il sistema di patching prevede delle pianificazioni con archi temporali più o meno lunghi. Una patch può richiedere a volte anche mesi prima di essere installata. Le informazioni sulla minaccia servono a determinare se quel processo debba essere accorciato oppure no. Se si hanno indicatori che la propria azienda sia sotto attacco da gruppi specifici e questi gruppi siano in grado o abbiano già sfruttato una determinata vulnerabilità, allora sarebbe il caso di accorciare i tempi e chiedere il rilascio della patch quanto prima. Gli indicatori possono derivare da campagne di phishing subite, da alert scattati sul perimetro esterno e così via.
In sintesi, per avere un sistema efficiente ed efficace di gestione delle vulnerabilità, è necessario avere tutta una serie di altre informazioni: un database con tutti gli asset presenti in azienda; i servizi supportati dai singoli asset e il valore che questi servizi creano; almeno una fonte informativa sulle vulnerabilità pubblicate ed eventuali exploit ad esse associate; dove possibile anche informazioni sui modelli di attacco in cui potrebbero essere utilizzate e relativi gruppi criminali. In questo modo, fintanto che la vulnerabilità non è sanata, sarebbe possibile comunque monitorare altri indicatori per proteggere i servizi.
Questo solo per pesare la vulnerabilità e poterla comunicare con il giusto dettaglio informativo ai gestori del patching. Avere una correlazione di tutte queste informazioni potrebbe portare l’azienda a passare da un concetto di rischio statico a rischio dinamico. La valutazione del rischio cyber non si limiterebbe più a una semplice fotografia nel tempo ma a un flusso continuo. I decisori potrebbero avere la possibilità, in ogni istante di verificare il livello del rischio cyber associato al servizio. Ne gioverebbero anche i processi di crisis management, incident handling e business continuity. Il tutto però richiede sia un forte commitment da parte dei business owner, sia una forte collaborazione fra tutte le anime dell’azienda che dovrebbero fare sistema. È il business owner che deve imporre questa filosofia di pensiero sia alle funzioni IT sia alle funzioni di sicurezza.
Autore: Massimo Cappelli
