Vai al contenuto principale
Blog Tanium

Attacco WannaCry: Come la paura del cambiamento ci ha portato qui

In qualità di Chief Security Architect di Tanium, Ryan Kazanciyan ha potuto osservare da vicino le procedure di risposta interne adottate da decine di aziende in tutto il mondo a seguito dell’attacco del ransomware WannaCry. Qual è stata la sua principale conclusione? La resistenza istituzionalizzata al cambiamento – e non una semplice negligenza – è una delle ragioni principali per cui così tante aziende si sono ritrovate in una posizione di vulnerabilità. Ecco cosa può fare al riguardo.

3D illustrazioni raffiguranti personaggi colorati disposti attorno a un grande punto interrogativo

(Image: Arek Socha / Pixabay)

Mentre assistiamo all’ampliarsi del circolo delle accuse sulla scia dell’attacco del ransomware WannaCry, è naturale chiedersi perché le vittime abbiano tardato così tanto ad adottare misure di protezione facilmente disponibili. Da due mesi era disponibile una patch che avrebbe potuto impedire questa epidemia. Il malware ha sfruttato una funzionalità di Windows che era stata dismessa già da quattro anni. Ciò che spesso viene trascurato è che la resistenza istituzionalizzata al cambiamento – e non la semplice negligenza – è una delle ragioni principali per cui così tante aziende si sono ritrovate in una posizione di vulnerabilità.

Nel corso dell’ultima settimana, ho avuto l’opportunità di osservare da vicino alcune delle procedure interne di risposta adottate da decine di aziende in tutto il mondo a seguito dell’attacco del ransomware WannaCry. Ho riscontrato discrepanze fin troppo frequenti tra percezione e realtà.

Cominciamo con la discrepanza più evidente: molte organizzazioni operavano partendo dal presupposto che la maggior parte dei propri sistemi fosse stata aggiornata con le patch. Hanno invece scoperto che la percentuale di computer vulnerabili presenti nei loro parchi era a due cifre. Altri non avevano modo di verificare se i sistemi fossero stati riavviati o se fossero state apportate o fossero entrate in vigore altre modifiche alla configurazione volte a ridurre i rischi. Altri ancora hanno continuato a mostrarsi titubanti nel “dare il via libera” alle correzioni, poiché non erano certi di riuscire a Detect rapidamente eventuali conseguenze indesiderate, né di poter annullare le modifiche qualora fosse necessario.

La situazione non è un caso isolato limitato all’attacco WannaCry. Sebbene la spesa annuale per la sicurezza informatica a livello mondiale si avvicini ai 100 miliardi di dollari nel 2017, le aziende continuano a incontrare difficoltà nell’affrontare attività di base relative alla gestione dei sistemi, come l’applicazione delle patch, che sono fondamentali per la cosiddetta “igiene della sicurezza”. Per comprendere il motivo di ciò, occorre innanzitutto esaminare il modo in cui operano la maggior parte delle organizzazioni IT.

Nel corso dell’ultimo decennio, gli sviluppatori di software hanno abbracciato il movimento DevOps e le cosiddette metodologie agili. Tali approcci pongono l'accento sullo sviluppo, il collaudo e la consegna iterativi e rapidi delle soluzioni all'interno dell'azienda. Tuttavia, i processi di ingegneria e di controllo delle modifiche in molti ambiti delle operazioni IT e di sicurezza sono rimasti relativamente antiquati e ostinatamente restii ad adeguarsi all’evoluzione. Si tratta di uno scontro tra filosofie: da un lato, un cambiamento rapido, graduale e automatizzato; dall’altro, un approccio metodico, pianificato e vagliato, che agisce su larga scala.

WannaCry solleva gravi problemi a livello organizzativo

Esistono ragioni molto concrete e pratiche per cui i settori IT e della sicurezza sono restii al cambiamento. La maggior parte delle infrastrutture IT è un miscuglio di tecnologie legacy e moderne, messe insieme alla bell’e meglio per funzionare insieme nel corso del tempo. Secondo Frost & Sullivan, un’organizzazione media utilizza da quattro a sei sistemi operativi sugli endpoint e da quattro a sette sistemi operativi diversi sui server. Su queste piattaforme possono essere eseguite centinaia di applicazioni fondamentali per l’attività aziendale, alcune delle quali più sensibili alle modifiche a livello di sistema operativo rispetto ad altre. Inoltre, la responsabilità operativa della gestione di tutta questa infrastruttura è spesso caratterizzata da una forte compartimentazione: l’informatica per gli utenti finali, l’amministrazione dei server e la supervisione delle applicazioni sono tutte suddivise tra numerosi team che non sempre operano allo stesso ritmo. L’inserimento di appaltatori e fornitori esterni nel quadro generale introduce un’ulteriore complessità. E nessun individuo o team desidera essere responsabile di un malfunzionamento di un sistema cruciale a causa delle proprie operazioni di correzione.

Quando le esigenze aziendali richiedono una disponibilità ininterrotta del sistema, è facile comprendere perché le aziende adottino un approccio prudente nei confronti di determinati tipi di modifiche IT. E, a onor del vero, tutti i moderni processi di controllo delle modifiche prevedono misure per la gestione delle emergenze. Tuttavia, anche quando l’urgenza dell’incidente WannaCry richiedeva la flessibilità necessaria per apportare modifiche, molte organizzazioni continuavano a essere limitate dalle proprie operazioni di sicurezza e dalla tecnologia di gestione dei sistemi. Ciò evidenzia un circolo vizioso: in assenza della capacità tecnica di attuare cambiamenti in modo affidabile e rapido e di monitorarne i risultati su larga scala, le persone creano un “freno” sotto forma di ulteriori deliberazioni, procedure e processi di consenso. Ciò compromette ulteriormente la loro agilità e limita l’efficacia delle soluzioni in cui hanno investito.

Purtroppo, la patch che avrebbe potuto impedire la diffusione di WannaCry presentava una combinazione “perfetta” di caratteristiche tali da rallentarne l’adozione:

  • Ha interessato quasi tutte le versioni di Windows, il che comporta un maggior numero di ruoli e tipi di sistema da sottoporre a test.
  • Ha richiesto un riavvio (non tutte le patch lo richiedono), rendendo necessario un coordinamento della pianificazione per ridurre al minimo l’impatto sulle attività aziendali.
  • Inizialmente non era stato rilasciato per Windows XP e Server 2003 Windows , ma solo dopo l'epidemia di WannaCry. Sebbene entrambi i sistemi operativi abbiano raggiunto la fine del ciclo di vita, continuano a essere presenti in molti ambienti. Il loro numero sta diminuendo – secondo quanto riportato dal NHS, ad esempio, solo circa il 5% dei sistemi presenti nel proprio inventario utilizzava XP – ma tali sistemi vengono spesso impiegati per supportare dispositivi legacy di importanza critica.

Alla luce di questi ostacoli tecnici e procedurali, non sorprende che WannaCry abbia avuto un impatto così devastante, in particolare in settori quali quello sanitario.

La verità inquietante è che WannaCry avrebbe potuto avere conseguenze ben più gravi. Al momento della stesura del presente articolo, il malware aveva infettato “solo” alcune centinaia di migliaia di sistemi. Al contrario, Conficker (che ha sfruttato una vulnerabilità altrettanto diffusa dell’ Windows , nel 2008) si è diffuso su oltre 10 milioni di computer. Molte organizzazioni hanno semplicemente avuto la fortuna di sfuggire al mirino delle campagne di attacco iniziali. Eppure, la nostra dipendenza dai sistemi informatici nel 2017 fa sì che gli effetti di questo attacco siano stati avvertiti in modo molto più acuto rispetto ad altri che lo hanno preceduto.

I responsabili IT devono cogliere questa opportunità per promuovere la modernizzazione dei processi e delle tecnologie alla base della gestione dei sistemi e delle operazioni di sicurezza, senza limitarsi semplicemente a migliorare il rilevamento degli attacchi e la risposta agli stessi. Quando gli attacchi futuri riusciranno inevitabilmente a eludere le nostre prime linee di difesa, un approccio agile all’igiene della sicurezza potrà impedire che infezioni su piccola scala e sparse si trasformino nella prossima epidemia globale.

Informazioni sull’autore: Nel suo ruolo di Chief Security Architect presso Tanium , Ryan Kazanciyan vanta oltre 14 anni di esperienza nei settori della risposta agli incidenti, dell’analisi forense e dei test di penetrazione. Ryan supervisiona la progettazione e la roadmap delle soluzioni " Threat Response " di Tanium e dirige il team "Endpoint Detection and Response" (EDR) di Tanium . Prima di entrare a far parte di Tanium, Ryan ha coordinato le attività di indagine e risoluzione dei problemi presso Mandiant , collaborando con decine di organizzazioni incluse nella classifica Fortune 500 che erano state oggetto di attacchi mirati. Ryan ha formato centinaia di esperti nella gestione degli incidenti in qualità di istruttore per Black Hat e per la squadra informatica dell’FBI. È uno degli autori del volume “Incident Response and Computer Forensics, 3ª edizione” (McGraw-Hill, 2014). Ryan lavora inoltre come consulente tecnico per la serie televisiva “Mr. Robot”, dove collabora con gli sceneggiatori e il team di produzione per ideare gli attacchi informatici rappresentati nella serie.