Tags: cybersecurity

Spesso l’idea di gestione di una vulnerabilità è associata all’idea di installare una patch. Ovviamente questa potrebbe in tanti casi essere una eccellente soluzione di cybersecurity, ma non necessariamente e non sempre questo è possibile.

Le vulnerabilità non sono solo software ma anche di processo

Durante l’attacco Stuxnet ad esempio, è noto ai più che sono state sfruttate 4 vulnerabilità non conosciute (o zero-day) su Windows. In verità questo attacco è passato alla storia per aver fatto comprendere al mondo intero che anche una centrale nucleare, totalmente isolata, potesse essere attaccata e che i sistemi industriali non fossero più immuni da attacchi di tipo cyber.

L’attacco ha potuto avere successo in quanto un dipendente della centrale ha preso una chiave USB trovata chissà dove e la ha inserita in un PC collegato alla rete.  Dopo quel momento, il comportamento del dipendente è stato stigmatizzato in quanto scorretto e lui stesso ritenuto uno sprovveduto o addirittura uno sleale, senza soffermarsi sul fatto che se in azienda ci fosse stata una prassi che imponeva di non inserire chiavi USB nei PC, il malcapitato non avrebbe commesso nessun atto potenzialmente pericoloso per la cybersecurity. 

In questo caso chi ha sferrato l’attacco ha sfruttato non solo le 4 vulnerabilità su windows, ma anche una vulnerabilità di processo. La vulnerabilità è quindi una debolezza dell’intero sistema che viene sfruttata da chi attacca ai fini di eseguire azioni non autorizzate.

Avendo compreso che la cosa non riguarda solo il software e l’hardware ma anche i processi, un altro elemento da considerare è che non sempre le vulnerabilità possono essere risolte tramite installazione di una patch. Infatti, l’installazione di una patch deve avvenire in un ambiente di test in accordo alle buone pratiche di service management. Ma quanti possono permettersi un ambiente di test ragionevolmente simile all’originale? In ambienti IT questo è verosimile, ma in ambienti industriali non sempre è possibile. In ogni caso, ogni qual volta venga testata una patch che vada a modificare il comportamento di strutture critiche come una centrale nucleare, un treno o un aereo, la fase di test è inevitabile per scongiurare il rischio di generare disservizi estremamente critici.

L’identificazione delle vulnerabilità e l’analisi “what if”

Spesso pertanto è necessario convivere con le vulnerabilità, identificando quei controlli necessari (in fase di prevenzione, identificazione e risposta ad un attacco) che vadano a ridurre il rischio che qualcuno possa sfruttare le vulnerabilità.

Anche identificare una vulnerabilità alla cybersecurity su questi sistemi non è facile. Infatti, i tool utilizzati (sempre e solo da personale estremamente esperto) sono talvolta invasivi. Ancor di più lo sono i tool e le attività fatte durante il penetration test, orientato a simulare un attacco e verificare la robustezza dei controlli di sicurezza identificati.

Infine, le attività di assessment o penetration test sono spesso focalizzate su quanto si conosce. Ma una vulnerabilità non sempre si conosce, anzi dal momento che i sistemi sono creati dall’uomo, sono per natura imperfetti e quindi vulnerabili. Più si introducono sistemi, più ci saranno vulnerabilità che possono essere sfruttate. Paradossalmente, anche le patches sono a loro volta insiemi di manufatti software e hardware, cambi di configurazione.  Pertanto, anche installare molte patch introduce nuove vulnerabilità.

Quindi un corretto approccio alla cybersecurity dovrebbe essere basato sull’analizzare cosa possa succedere nel caso che qualcuno scopra una vulnerabilità del sistema: una analisi ‘what if’ su ogni nodo del sistema.

Vulnerabilità zero-day e vulnerabilità conosciute

Abbiamo parlato di vulnerabilità conosciute e non ( zero-day ). Gli zero-day raccolgono spesso l’interesse delle conferenze sul tema cybersecurity e di molti autori. Infatti se l’utilizzatore di un sistema non ne conosce le vulnerabilità, sicuramente è esposto.  Ecco perché i maggiori fornitori condividono informazioni relative alle vulnerabilità dei propri sistemi che verranno poi etichettate come CVE. Attenzione però, nel momento in cui una vulnerabilità diventa pubblica, è necessario identificare delle soluzioni per mitigare il rischio di un attacco.

Perché se una vulnerabilità è non conosciuta, a meno che un hacker sia fortemente motivato a violare il sistema, probabilmente il navigatore casuale non riuscirà a sfruttarla. Se una vulnerabilità è conosciuta invece, un navigatore anche casuale potrebbe facilmente riconoscerla e sfruttarla. Pertanto attenzione alle vulnerabilità zero-day, ma ancora di più alle vulnerabilità conosciute.