Meltdown-Spectre: i consigli per le aziende | Digital4Trade
Questo sito utilizza cookie per raccogliere informazioni sull'utilizzo. Cliccando su questo banner o navigando il sito, acconsenti all'uso dei cookie. Leggi la nostra cookie policy.OK

Sicurezza

Meltdown e Spectre, perchè le aziende rischiano di più

di Redazione #Digital4Trade

09 Gen 2018

Le aziende sono più a rischio per Meltdown e Spectre perchè, rispetto ai comuni utenti, hanno a che fare con fenomeni come cloud e virtualizzazione

Come abbiamo raccontato in questo articolo, le falle nei chip che sono state scoperte dal team di sicurezza di Google interessa tutti gli utenti, nessuno escluso, dal momento che interessano tutti i processori prodotti negli ultimi decenni. Quel che è certo, come ha raccontato ad Agenda Digitale l’esperto di sicurezza Alessio Pennasilico, è che di fronte ai pericoli causati dalle vulnerabilità Spectre e Meltdown, le aziende hanno qualche problema in più. Oltre ai problemi in comune con gli utenti consumer (su computer e smartphone in particolare), le aziende fronteggiano due ulteriori scenari di rischio: i servizi in cloud utilizzati dall’aziende e i suoi desktop virtuali.

Cloud: se un’azienda ha dati in cloud su risorse condivise con altri utenti, uno di questi potrebbe sfruttare la vulnerabilità e così accedere ai dati presenti sugli altri sistemi che condividono la stessa macchina. Risorse condivise significa infatti che tutti i sistemi, di aziende diverse, usano lo stesso processore. Un criminale può utilizzare un programma malevolo che sfrutta le note vulnerabilità del processore e così colpire tutti i sistemi relativi.

Desktop virtuali: la situazione è quella di un’azienda con diversi sistemi con desktop virtuali. Basta che solo un utente di questi venga infettato da un programma che sfrutta le note vulnerabilità perché siano a rischio i dati di tutti i desktop virtuali. Anche in questo caso infatti le risorse hardware sono condivise.

 

Per le aziende meglio rispettare le policy

Il problema è grave, ma il gestirlo in contesti aziendali non è così banale: la semplice pubblicazione delle patch da parte dei produttori potrebbe non bastare per risolvere in tempi brevi. Bene che ci siano le patch, infatti, ma se aggiorno il browser di tutti i pc della mia organizzazione e di conseguenza smette di funzionare il mio CRM o gestionale (che di colpi diventa incompatibile con la nuova versione del browser), per prevenire un possibile attacco ho di fatto creato un danno di business ingente. Vale per i browser come per i sistemi operativi, il cui aggiornamento potrebbe rendere di colpo inutilizzabile un hardware aziendale, per esempio. Se anziché pensare ai pc pensiamo ai server, immaginiamo se la patch smette di far funzionare un servizio su un server… di nuovo danno di business.

Astraiamo ancora di più: in contesto large enterprise magari server e desktop sono virtualizzati. Se metto una patch su sistema di virtualizzazione e smette di funzionare qualche decina di server? Per tutte queste ragioni è importante che nelle aziende, nonostante la bagarre ed il rilievo mediatico del momento, vengano rispettate quelle che dovrebbero essere le normali procedure operative e policy per la gestione degli aggiornamenti, con l’applicazione in un contesto controllato (magari l’ambiente di test, di sviluppo, il pre-esercizio, l’ambiente per la formazione, o comunque ambienti non di produzione).

 

Discorso a parte per il cloud: se parte dei miei servizi che gestiscono dati critici gira su servizi di terzi (penso ad Azure, AWS, GoogleAPP, ma potrei citare altri provider di IaaS o SaaS). Dobbiamo quindi accertarci che il nostro fornitore stia agendo per affrontare il problema. Può essere una questione critica con fornitori minori.
Se il mio fornitore di CRM in the cloud o di gestione HR in the cloud ignora il problema e rubano i miei dati dalla sua infrastruttura, potrei avere delle responsabilità e di certo subire danni (anche solo di immagine). Allora bisogna sapere cosa prevede il contratto (il fornitore deve risolvere il problema? Il tutto è compreso nel servizio o comporta costi aggiuntivi? Entro quando deve farlo? Quali le sue e le mie responsabilità in caso di incidente?).
Purtroppo è un tema governato solo se gestito a monte. Cosa che non solo si consiglia di fare come best practice, ma che in ottica GDPR diventa indispensabile per il principio di accountability.

Come limitare i danni

Come sempre, chi si era preoccupato di politiche, procedure, contratti, prima dell’emergenza ora sa cosa fare e riuscirà a limitare i danni facendo scelte ragionate e guidate da criteri oggettivi. Gli altri dovranno prendere decisioni strategiche sull’onda di situazioni stressanti, guidati dall’emotività e cercando di calmierare i danni, sperando di non farne di più gravi per eccesso di zelo, avventatezza.

  • arrow_upward
  • arrow_downward
  • share
    18 Share
Redazione #Digital4Trade

Profilo ufficiale della redazione di Digital4Trade